[lkml]   [1998]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] [PATCH] Dirty pages in the page cache

On 12 Jan 1998 21:49:38 -0600, (Eric
W. Biederman) said:

>>> The basic idea of use is a filesystem will set an extra dirty on a
>>> page, when a write occurs to it. And if the dirty bit is set it is
>>> garanteed that before the page is removed from memory `writepage' will
>>> be called.

ST> One big question with this: _should_ this sort of thing be done directly
ST> in the page cache? Most filesystems will require extra information in
ST> order to keep their current write semantics. Ext2fs will require
ST> information about which blocks within the buffer are dirty, especially
ST> for short files on 1k block filesystems. NFS will require credential
ST> information.

> I don't know if we need to do this for all filesystems. Network
> filesystems seem to be a good canidates. We could include an extra
> void *pointer in struct page cache that could be used for tracking
> extra information (or contain it directly). Though we could as easily
> reuse the struct buffer_head as a generic data pointer, for a page
> cache page. (But usually struct buffer heads?)

Overloading the buffer_head would be a good idea, rather than adding
even more information to the page_struct. There are plenty of free
bits in the flags word which will let us tell whether the pointer
refers to buffers or not.

> My primary target (besides my own fs) when I designed it was
> filesystems with compressed files. That needs seperate caching of
> the file data, and what is written to the disk. Something the page
> cache is good at.

True. Of course, you _could_ do this by modifying the buffer cache at
write() time, but by deferring that operation you can batch up your
writes and hopefully compress more efficiently.

> Also one tricky element is reducing cache size when memory is low.
> If shrink_mmap doesn't shrink the page cache all kinds of interesting
> things can occur. System slow downs, getfreepage lockups etc. This
> is an important justification for doing it in the page cache directly
> so shrink_mmap can free the pages, or at least start freeing them.

That is just as much of a problem whichever way you do it. If we use
the buffer cache, we'd be doing it via buffers which kill themselves
after IO. That is actually _better_ than what we have now, where the
buffers persist until reclaimed (reclaiming buffers when a lot of them
are dirty can be hard due to fragmentation), *and* we can have
separate data for the same file page in the page cache. The
page->buffer link will still let us flush dirty data via

> My thought (assuming we are using generic_file_write), is that
> update_page can set do the filesystem specific setup of just how it is
> to be done and set the dirty_bit, and then write_page will be called
> when the dirty bit is set. So it is still optional, and the specifics
> are controlled by the individual filesystems.

Yes, but only as long as the whole mechanism is entirely under
filesystem control.

ST> There's a big reason to keep the page cache dirty, though, and that is
ST> for speed of fsync(). Fortunately, the page->buffers pointer would give
ST> us an easy way of finding (and syncing) all dirty buffers associated
ST> with each page on an inode's page-cache ring.

> A definite advantage, I handn't realized. Still you can use the page
> cache dirty bit as a signal that (at least one buffer), is dirty. The
> replication wouldn't hurt.


> Still this leaves open the question of what to do about readpage &
> writepage, and the fact NFS needs dentries for them.

Overloading the page->buffer entry, as you mentioned earlier, is a good
way to give the fs some way to maintain that information. Beyond that
it is up to the fs itself to track the information it needs to complete
the write_page(). The VFS has _got_ to call the filesystem directly
when a write() occurs, so that it can maintain the handles/dirents/
credentials/whatever-else-it-needs to complete the write.
mmap(MAP_SHARED) can't do this directly, of course.


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