lkml.org 
[lkml]   [1998]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] [PATCH] Dirty pages in the page cache
On 13 Jan 1998 05:59:30 -0600, ebiederm+eric@npwt.net (Eric W. Biederman) said:

> O.K. Then I guess the basic task is a follows.
> For writepage (which really hasn't been used yet). Revert that to use
> an inode (instead of a dentry).

We've already come across the problem that NFS needs dentries, not
inodes. We solve this currently by doing all of the flushing from
virtual memory to filesystem when we traverse the vm region or page
tables: that way, we have the relevant vma in hand when we spot dirty
data, and can get the dentry from that. We've recently got a patch
which traverses vma's on a page clearing pte dirty bits whenever we
msync such a page.

So, I guess the question is, why _exactly_ do you want to have dirty
page cache pages? I'm not saying it's a bad idea, but you do need to
identify precisely what problem you are trying to solve before we can
say whether or not the solution is a brilliant idea!

> Reimplement the buffer_head pointer as a generic pointer, with a flag
> that says it's a buffer_head pointer.

Possibly. The existing filesystems don't need it. You could certainly
make things easier for some network filesystems by maintaining dirty
data for them, but who is responsible for that dirty data? What happens
when different users, or perhaps different dirent aliases for the same
file, dirty the same page? These have to be filesystem policy
decisions. I guess this means that the page cache changes you propose
really are purely facilities for filesystem use, not to be used
directly by any generic file IO routines.

So, once we have a page cache which can hold dirty data, who are you
proposing is responsible for flushing that dirty data to backing store?
I'm not sure whether you are suggesting a completely new mechanism for
maintaining asynchronously written dirty data with callbacks into the
filesystem, or whether the page cache extensions will do nothing extra
on their own but will be called by the filesystem when it decides for
itself that data needs to be written out.

> Update my current patch to these changes.

> Test it.

> Send it to Linus?

> Buffer cache changes, and ext2 support, and other filesystems.
> Once the basic code is in place.

The ext2 support doesn't _need_ any changes to the page cache! It
doesn't, strictly speaking, need any buffer cache changes either, but a
new free-after-bdflush buffer type would be highly desirable just from a
performance point of view --- there's no reason to maintain the physical
view of the data past the point where it has reached disk.

Cheers,
Stephen.

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.051 / U:1.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site