On Wed, May 05, 1999 at 02:06:36PM -0400, Alexander Viro wrote:
> On Wed, 5 May 1999, Steve Dodd wrote:
> > On Wed, May 05, 1999 at 12:41:27PM -0400, Alexander Viro wrote:
> > > Aha. Steve, I didn't really look into NTFS driver's guts
> > Very wise :)
> Now I did ;-) Why on the earth do you use *positive* values for
> errors? I didn't finish wading through the directory-scanning logics
> yet...
First, the standard disclaimer: I'm not the author of the NTFS driver, and
I don't consider myself a kernel hacker by any stretch of the imagination. I
got interested in it when it started blowing up around 2.2.0/1. That said, I'd
love to become au fait with the kernel, and fs-related bits seem to be one of
the more interesting places to start...
Error values: Pass. Is there a good reason not to? The values get inverted
before being returned to the VFS layer (except for the odd mistakes which you
caught the other day). I thought -ve error returns were a hack for situations
were the function normally returned a value, and one had to avoid the global
errno variable that's used in, e.g. libc.
If you think it's an advantage it shouldn't be too hard to change...
> Umm... I don't think that you'll hit something nasty with them
> now, with the interface changes already in place. There was quite a bunch
> of races in that area and half of filesystems missed (fs-independent)
> checks. Now checks went to VFS and race-prevention did the same.
Good :) That's one worry over, then.
[master file table]
> It may mean nastiness with locking... (disclaimer - I didn't check
> the actual code yet).
Thinking about this, I'm worried about the re-entrancy and SMP-safeness
of the NTFS stuff at the moment. The NTfs driver holds the MFT inode open
all the time, so that may not be such an issue there. I'm still worried about
the SMP-safeness though. I'll have to look and see what locking happens at
the VFS layer.
One of the things that makes the code a bit confusing is that it is designed
to be easily portable. There are the common files (attr.c, dir.c, inode.c,
super.c, util.c), and then platform specific ones. At the moment the supported
platforms are linux21, linux20, 44bsd & user (the user-space utils).
At the moment I don't think the code interacts with the icache well; whenever
a change is made to an inode, it's written out before leaving the driver. I'm
planning to make it use mark_inode_dirty(), iget() and iput() properly soon.
I need the iget() and iput() stuff to avoid a nasty (but obvious) race with
updating directory indexes when file sizes change: NTFS keeps a copy of the
file size in the directory entries, which is a pain.
Also, NTFS - and the WinNT driver - support logging / journalling. Ideally
we should implement that but I don't think anyone has really considered it
yet, mainly because the format of the Logfile on disk isn't clear and is
certainly not documented (don't you just _love_ M$?). I understand you're
working on a journalled filesystem (or is it a journalling layer for
existing filesystems?); I'd be interested in seeing the code.
The 'light-weight inode' system discussed a while back for 2.3 sounds
interesting, too..
> ObknfsdCode: for non-directories we don't really need to go the
> whole way to root. Unhashed dentry is more than enough to make all _file_
> operations work. We need a hashed dentry (i.e. properly sitting in the
> directory tree) only for directory fhandles...
Hmm.. That's right over my head at the moment. Your idea of allowing the
filesystems to provide their own methods for creating invariant filehandles
sounds like a good idea, though. Would you just implement it as another
super_ or inode_operation, with a default implementation in VFS for sane,
UNIX-like filesystems?
S.
-- A neutron walks into a bar. "I'd like a beer" he says. The bartender promptly serves up a beer. "How much will that be?" asks the neutron. "For you?" replies the bartender, "no charge"- 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/