Btree directories (Re: Status of HFS+ support)
Alexander Viro
viro at math.psu.edu
Thu Aug 31 08:49:30 EST 2000
On Wed, 30 Aug 2000, David A. Gatwood wrote:
> Also, race protection in the VFS layer doesn't make sense either, because
> how can the VFS possibly assume anything about the structure to know what
> it can and can't allow to happen concurrently? And the sticky directory
> thing... that's the filesystem's responsibility to implement that, not the
> VFS layer.
Oh, really? How about rename()/rename() ones? I mean, those that were
_totally_ fucked up in 4.4BSD all over the friggin' place. How about
rename()/rmdir()? (ditto) Why should _that_ be duplicated into every fs,
with its own set of bugs in each of them?
> The VFS layer shouldn't even care if the underlying filesystem supports
> ownership, much less sticky directories. It should simply pass
> information about the operation and who wants to do it to the filesystem
> and the filesystem should decide if that's a legal operation or not.
> Anything more depends on an inode-structured filesystem, or at least
> faking an inode structure for the VFS layer, which is a waste of system
> overhead with little or no obvious benefit.
Again, BS. You have ->permission() for that.
> > VFS does not rely on inode numbers and it does not pass them around. Even
>
> But it does, at least in 2.2.14. I'm looking at the code right now. The
> word inode appears 40 times in the dcache.c file alone. The inode
> number is stored in the dentry as dentry->d_inode, and is used for several
Number? Look into dcache.h and fs.h. BTW, fs-independent part of struct
inode in Linux _is_ vnode. Normal, sane BSD/SunOS vnode.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-dev
mailing list