All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phillip Susi <psusi@cfl.rr.com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: linux-fsdevel@vger.kernel.org,
	Linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: unified page and buffer cache?
Date: Fri, 7 May 2010 11:45:34 -0400	[thread overview]
Message-ID: <4BE4359E.9020400@cfl.rr.com> (raw)
In-Reply-To: <20100507135329.GA17259@parisc-linux.org>

On 5/7/2010 9:53 AM, Matthew Wilcox wrote:
> The problem you're seeing is aliasing in the page cache, not a failed
> unification of the buffer and page caches.  Pages are addressed by
> (mapping, offset).  Each inode generally has its own mapping.  Depending
> on the file system, directories may be addressed by their own inode's
> mapping, or by the block device's mapping.

If there are two mappings that don't know about each other, then the
caches don't seem very unified to me.  If I write to the file and that
data sits in the mapping for the inode, then I read the corresponding
blocks though the block device, and it has a different mapping, then I
read the old data off the disk instead of the new data in the cache.  I
thought that this exact problem had been fixed long ago.

> Resolving aliasing would be horribly expensive, so it's unlikely to
> happen.

Back to the drawing board I guess.  Maybe ext could be fixed to use an
inode mapping for directories instead of relying on the block device
mapping, then I could readahead() the directory instead of having to go
to the block device at all.

  reply	other threads:[~2010-05-07 15:45 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-19 15:51 readahead on directories Phillip Susi
2010-04-21  0:44 ` Jamie Lokier
2010-04-21 14:57   ` Phillip Susi
2010-04-21 16:12     ` Jamie Lokier
2010-04-21 18:10       ` Phillip Susi
2010-04-21 20:22         ` Jamie Lokier
2010-04-21 20:59           ` Phillip Susi
2010-04-21 22:06             ` Jamie Lokier
2010-04-22  7:01               ` Brad Boyer
2010-04-22 14:26               ` Phillip Susi
2010-04-22 17:53                 ` Jamie Lokier
2010-04-22 19:23                   ` Phillip Susi
2010-04-22 20:35                     ` Jamie Lokier
2010-04-22 21:22                       ` Phillip Susi
2010-04-22 22:43                         ` Jamie Lokier
2010-04-23  4:13                           ` Phillip Susi
2010-04-21 18:38       ` Evgeniy Polyakov
2010-04-21 18:51         ` Jamie Lokier
2010-04-21 18:56           ` Evgeniy Polyakov
2010-04-21 20:02             ` Jamie Lokier
2010-04-21 20:21               ` Evgeniy Polyakov
2010-04-21 20:39                 ` Jamie Lokier
2010-04-21 19:23           ` Phillip Susi
2010-04-21 20:01             ` Jamie Lokier
2010-04-21 20:13               ` Phillip Susi
2010-04-21 20:37                 ` Jamie Lokier
2010-05-07 13:38 ` unified page and buffer cache? (was: readahead on directories) Phillip Susi
2010-05-07 13:53   ` Matthew Wilcox
2010-05-07 15:45     ` Phillip Susi [this message]
2010-05-07 18:30       ` unified page and buffer cache? Matthew Wilcox
2010-05-08  0:50         ` Phillip Susi
2010-05-08  0:46       ` tytso
2010-05-08  0:54         ` Phillip Susi
2010-05-08 12:52           ` tytso

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=4BE4359E.9020400@cfl.rr.com \
    --to=psusi@cfl.rr.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew@wil.cx \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.