[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.024 / U:20.152 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site