Messages in this thread | | | Date | Wed, 17 Feb 1999 14:19:47 -0500 (EST) | From | Alexander Viro <> | Subject | Re: fsync on large files |
| |
On Wed, 17 Feb 1999, Linus Torvalds wrote:
> > > On Wed, 17 Feb 1999, Alexander Viro wrote: > > > > > > Umm.. We _never_ use "." and ".." in filesystems. Never. > > > > Linus, please take a look at knfsd. > > Are you talking about [snip]
Nope. I'm talking about the stuff in fs/nfsd/nfsfh.c: lookup_inode() and get_parent_ino(). And yes, there is quite an interesting comment between them ;-)
> then yes, there is lots of historical stuff in there. knfsd was originally > written for older kernels. But note the comments. > > That's kind of my argument: we _used_ to need to have "." and ".." and for > filesystems that didn't have them (like the iso9660 CD-ROM filesystem) we > went to a fair amount of trouble to try to handle them correctly (and > there were still special cases where we didn't, as far as I can tell). > With the dentries, that just went away, but we still have cruft there.
Oh, yes. We have all sorts of cruft in fs/*/*, no doubt. Stats on last variant of rename patch - 388 lines in, 757 lines out. And that's after similar stats from the previous runs. And much more can be cleaned up. Lots of filesystems check for directory being directory. All of them (except AFFS, damnit) check for the target of link() being non-directory (instead of VFS doing that). nfsd/vfs.c duplicates namei.c big way. Dealing with mknod() is duplicated in all filesystems that do it. Minixfs and sysvfs do very interesting things in rename() and truncate(). Don't get me started on FAT-dervied filesystems - wait for patch (when rename stuff will stabilize). Let's not go into the amount of cruft included from fs.h (embedded foo_inode_info and foo_sb_info). ObFoo_inode_info: would you object against defining FOO_I(x) as &((x).u.foo_i) and doing corresponding replacements in filesystems' code? I mean 1-to-1 replacement, giving the identical text after cpp. That alone would make transition to externally allocated fs-specific parts much easier when we'll finally go for it (there *is* a need for light-weight inodes). I'm not talking about rename patch, indeed - it's completeley separate story. Al
- 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/
| |