Messages in this thread | | | Date | Wed, 5 May 1999 14:06:36 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: ext2 warning in Linux 2.2.7 |
| |
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...
> > (mostly since it's R/O and thus all, erm, fun with rename()/unlink()/ > > rmdir() went without touching it). > > Mmmm. There _is_ actually experimental write code in there, but I don't think > we support rename(), unlink() or rmdir() yet, but it might happen soon. It's > not superficially difficult, and I've just added some code which will make it > easier. > > Code you explain what the issues are with rename() and friends? That way Were. > there's half a chance I might get it right first time! 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.
> > IIRC it's an FFS-derivative with B-trees used > > wherever possible. What are you using for inumbers? > > I don't know about FFS but I doubt it. All the fs metadata is actually stored > in files, which is neat in a twisted way. There's a Master File Table (=MFT), > which is a sequence of FILE records; the inumber is simply the index of the > FILE record. The MFT is actually stored in the $DATA stream of file in the > root directory called $MFT. I guess this makes access a bit slower, but it > means no special logic is required for extending it, and things like > filesystem defragmenters don't need to have (much) special handling for it.
It may mean nastiness with locking... (disclaimer - I didn't check the actual code yet).
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...
- 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/
| |