mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Juan <piernas@ditec.um.es>
Cc: Alexander Viro <viro@math.psu.edu>, linux-kernel@vger.kernel.org
Subject: Re: Addressing logically the buffer cache
Date: 16 Nov 2000 09:18:31 -0700	[thread overview]
Message-ID: <m1y9yj7uw8.fsf@frodo.biederman.org> (raw)
In-Reply-To: <Pine.GSO.4.21.0011141445450.5482-100000@weyl.math.psu.edu> <3A11C480.A27E406B@ditec.um.es>
In-Reply-To: Juan's message of "Wed, 15 Nov 2000 00:02:24 +0100"

Juan <piernas@ditec.um.es> writes:

> Alexander Viro escribió:
> > 
> > On Tue, 14 Nov 2000, Juan wrote:
> > 
> > > Hi!.
> > >
> > > Is there any patch or project to address logically the buffer cache?.
> > > Now, you use three parameters to find a buffer in cache: device, block
> > > number, and block size. But, what about if I want to find a buffer using
> > > a super block, an inode number, and a block number within the file
> > > specified by the inode number.
> > 
> > What's wrong with using the pagecache and per-page buffer_heads?
> 
> Suppose you are implementing a log-structured file system and a process
> adds a new logical block to a file. Besides, suppose that the segment is
> 512 KBytes in size. Usually, you don't want to write the segment before
> it is full. The logical block hasn't got a physical address because you
> don't build the segment until it is written to disk. So, what happens if
> another process wants to access to the new block?.
> 
> You can't assign a physical address to the new block because the address
> can change when the buffer is written to disk.

So you don't assign a buffer head until you make the final decision.
There are some interesting issues with how you track that your data
is dirty but otherwise all is well.
> 
> Perhaps, I'm wrong, but I think that the implementation of the BSD-LFS
> needs to address logically the buffer cache.

The linux vfs is quite different from the berkley one.  The linux page
cache is much closer to the berkley block cache, then the depricated
linux block cache.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

      reply	other threads:[~2000-11-16 17:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-14 19:56 Juan
2000-11-14 19:46 ` Alexander Viro
2000-11-14 23:02   ` Juan
2000-11-16 16:18     ` Eric W. Biederman [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1y9yj7uw8.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=piernas@ditec.um.es \
    --cc=viro@math.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®