>
> Alexander Viro writes:
>
> > Hmm... OK, folks. What about the following?
> > a) we don't give any warranties about preserving inode number of opened
> > file.
>
> OK.
>
> To avoid this, one could reserve the directory slot originally
> used to open the file until the file is closed. Subsequent calls
> to open can return the original inode number, no matter what the
> current on-disk value is.
D'oh. And rmdir becomes what? Reserving blocks used for directory?
Not to mention the bloody layering violation you'll get here. Actually, I
like the variant with bogus inumbers having no connection with the
directory entries (see posting from Linus). FAT doesn't have hardlinks,
so...
> The NFS solution is better, and it keeps the same inode number.
> It also reduces the time during which a crash would leave lost
> clusters in the FAT.
You'll get bloody unpleasant rmdir with that startegy. And lots of
nasty code (look through fs/nfs/dir.c for silly_rename() and friends).
We have two ugly kludges: NFS rename scheme and NCPFS bogus
inumbers. None of them is really supported by VFS. Neither is inumber
changing. BTW, thread re open by inode IMHO indicates that something is
missing in the whole i_ino/fhandle/st_ino thing. Maybe we are mixing
different thing together just because they are mixable on normal
filesystems.
Supporting bogus inumbers trick is easier for now. Wish it was
2.1 still. We'll have to clean NFS stuff (and it includes knfsd) in 2.3,
but let's don't start it in 2.2.0-pre.
> I note that Linux does not currently support the dirty flag:
>
> Field Offset Length
> Physical Drive Number 36 1
> Current Head 37 1 <--- now a dirty flag
> Signature 38 1
> ID 39 4
> Volume Label 43 11
> System ID 54 8
Albert, while we might do so we also have MSDOS on hands. What
will it do with plain, old, boring DOS 3.30?
-
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/