On Tue, 14 Mar 2000, Andrea Arcangeli wrote:
> On Tue, 14 Mar 2000, Alexander Viro wrote:
>
> >changes. And I would be much happier if somebody looked through
> >->truncate() searching for races. Andrea?
>
> Thanks. I'll look throught that ASAP.
>
> In my very humble and personal opinion the first thing to do now is to
> find a design solution to avoid the read_inode2 ugliness.
It's known for, erm, 8 or 10 years. Fast way to do that (real fast, real
ugly) - copy the code from nfsfh.c into the filesystem and make the
original call ->fhandle_to_dentry(fh) if such thing exists. Now you've got
all calls of iget() within your filesystem and can replace them with
variant that does _only_ lookup/allocation (no ->read_inode(), just mark
inode locked/new and return it). That way iget() becomes inode =
ilookup(); if (inode_is_new(inode)) fill_it(inode);
It's partially right (correct solution will look same in nfsfh.c side - if
filesystem provides a method we will call it instead of messing with that
shit in knfsd). However, such blind copy is _absolutely_ last thing I want
to see - for one thing it brings too intimate knowledge of locking stuff
into the fs, for another it's damn slow and inefficient. I believe that I
have better variant (I'm doing it on ext2, but it should be easy to port),
but I want to get it stable and finally sort the locking issues out
(->i_zombie is a big win here, but there is a couple of subtle things
remaining).
-
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 : Wed Mar 15 2000 - 21:00:27 EST