>> routines will fail - since they assume that page->private represents
>> bufferheads. So we need a better way to do this.
>
>They are not generic then. Some file systems store things completely
>different from buffer head ring in page->private.
I've seen these instances (and worked around them because I maintain
filesystem code that does in fact use private pages but not use the buffer
cache to manage them). I've always assumed they're just errors -- corners
that were cut in the original project to abstract out the buffer cache.
Anyone who has a problem with them should just fix them.
>I think that one reasonable way to add generic support for journalling
>is to split struct address_space into two objects: lower layer that
>represents "file" (say, struct vm_file), in which pages are linearly
>ordered, and on top of this vm_cache (representing transaction) that
>keeps track of pages from various vm_file's. vm_file is embedded into
>inode, and vm_cache has a pointer to (the analog of) struct
>address_space_operations.
>
>vm_cache's are created by file system back-end as necessary (can be
>embedded into inode for non-journalled file systems). VM scanner and
>balance_dirty_pages() call vm_cache operations to do write-out.
That looks entirely reasonable to me, but should be combined with
divorcing address spaces from files. An address space (or the "lower
level" above) should be a simple virtual memory object, managed by the
virtual memory manager. It can be used for a file data cache, but also
for anything else you want to participate in system memory management /
page replacement.
We're already practically there. Address spaces are tied to files only in
these ways:
1) The code is in the fs/ directory. It needs to be be in mm/ .
2) The "host" field is a struct inode *. It needs to be void *.
3) In a handful of places (and they keep moving), memory manager
code dereferences 'host' and looks in the inode. I know these
are trivial connections, because I work around them by supplying
a dummy inode (and sometimes a dummy superblock) with a few
fields filled in.
(Incidentally, _I_ am actually using address spaces for file caches; I
just can't tie them to the files in the traditional way; the cache exists
even when there are no inodes for the file).
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Filesystems
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
