Al,
Cool. After looking at this, having the file structure there (with void
*private_data) is quite useful and helpful, and isn't too much of a
hassle to implement.
I will make the necessary changes.
I have the page cache in NWFS fully implemented now, and am testing for
performance and file hole support -- took awhile to figure out that if
you register as a deviceless file system, generic_commit_write() no
longer works the way expecte for a local FS -- the buffer heads don't
seem to get flushed without external help -- like NFS does. I noticed
that (readpage*)() gets called a lot BTW.
Windows 2000 VM Cache Manager stores the actual sector runs when it
calls to map a page in it's version of a page * structure, then does the
I/O directly rather than ask the FS to do it via readpage(). It also
"remembers" these sector runs (they are stored as sector offset relative
to the start of a logical partition in their "page *page" structure),
whereas our page cache does not. The net is that they don't have to
remap reads all the time. I noticed that read mapping in NWFS Linux
page cache vs. W2K VM Cache Manager is about 1.5 times more frequent,
writes are on par however, and since W2K allows "coalesced" sector
requests to the driver (i.e. the VM cache manager "collapses" multiple
contiguous runs and issues a single I/O request for spanning sector
runs) it's slightly faster on FS I/O with NWFS on W2K vs. NWFS on Linux
(but not by much) :-)
"Roll your own" variable length sector run I/O requests at the
ll_rw_block() layer that issued a single I/O request to the disk drivers
would be a really nice feature to have in the future.
:-)
Jeff
Alexander Viro wrote:
>
> On Mon, 8 May 2000, Jeff V. Merkey wrote:
>
> >
> > I apologize for coming to the party late, but why are we changing this?
> > Sounds like we might be breaking people's FS code again.
> Rules for repair:
>
> a) if in readpage() you are interested only in the inode -
> replace dentry->d_inode with page->mapping->host and change the
> type of the first argument (unused now) to struct file *.
> b) if you can't get out with just an inode - use
> file->f_dentry instead of dentry and be done with that. However,
> c) if your readpage() needs to know _who_ reads the thing
> (e.g. you have credentials associated with the opener and need
> them in read request) - well, you have struct file * now, so
> you can store the stuff needed in the file->private_data. That's
> the case for several network filesystems.
>
> IOW, breakage is minimal and changes provide a clean way to deal with
> several nasties in NFS and p9fs. Check the thread - you may actually
> need it. Or not - I haven't look into nwfs code since _long_ ago and I
> can't tell off-hand how useful it is for your situation.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:12 EST