Messages in this thread | | | Date | Wed, 5 May 1999 20:57:39 +0100 | From | Steve Dodd <> | Subject | Re: ext2 warning in Linux 2.2.7 |
| |
(I've dropped H.J for the moment as I don't know that this is relevant to the NFS stuff; ditto nfs-devel)
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/
| |