From: "Hans Reiser" <reiser@idiom.com>
> >
> > If you mean that we need ID of parent for knfsd - see our discussion on
> > that stuff. VFS doesn't need to know parents of non-directories.
> >
> > Let me ask again:
> > a) is your "32 bit object ID" sufficient to
> > read/write/chmod/truncate/chown the file? Forget VFS, does the thing
> > contain enough information to do it in principle (aside of scanning the
> > whole tree, indeed)?
> No, we need the directory id plus the objectid (plus the offset) to know
what
> the key is.
I'm not sure if I understood your post:
does "directory id" mean the id of the directory the entry was initialy
created in? So the inode number of the current directory doesn't help?
knfsd currently stores the following members in the nfs handle: [fh_compose
in linux/fs/nfsd/nfsfh.c]
fhp->fh_handle.fh_dirino = ino_t_to_u32(parent->d_inode->i_ino);
fhp->fh_handle.fh_dev = kdev_t_to_u32(parent->d_inode->i_dev);
fhp->fh_handle.fh_xdev = kdev_t_to_u32(exp->ex_dev);
fhp->fh_handle.fh_xino = ino_t_to_u32(exp->ex_ino);
fhp->fh_handle.fh_ino = ino_t_to_u32(inode->i_ino);
fhp->fh_handle.fh_generation = inode->i_generation;
fh_xino is needed internally to check the security
fh_dev is needed to find the superblock.
fh_dirino ==NULL is used internally by knfsd.
fh_ino is the inode number. IIRC POSIX mandates that the 32-bit number is
unique and never 0?
fh_xdev is unused [was used for the sun emulation]
fh_generation is for uniqueness.
What about adding an explicit "get_persistant_id()" function pointer to
inode_operation?
it returns an 80-bit block.
knfsd stores it instead of fh_xdev, fh_dirino, fh_generation in the handle.
It might be possible to extent it to 96 bits, I don't understand when
fh_dirino is set to NULL.
Each filesystem must support "from superblock to dentry/in-memory inode"
with that 80-bit block and the 32-bit inode number of the entry.
> > b) if you have a directory, is its "32 bit object ID" sufficient
to
> > find ID of its parent?
given what? super block, in-memory inode?
If I'm correct, then a filesystem must
* get the parent of a directory [given the in-memory inode] with 0-bits
additional information.
* get the parent of a non-directory with the same 112 bits.
So VFS+knfsd need:
* super_block operation: go from 10 bytes + inode number to in-memory inodes
of both entry + it's parent.
* inode operation: get the 10-byte persistant id.
* inode operation, only supported for directories: get the parent.
I would prefer if VFS never uses the inode number for any lookups.
> > b) if you have a directory, is its "32 bit object ID" sufficient
to
> > find ID of its parent?
where do you need that?
IMHO
super_operations->get_dir_inode(dentry->inode->i_dirino)
is a bad idea,
dentry->inode->i_ops->get_parent();
gives far more flexibility to the filesystem. get_parent returns -ENOTDIR if
you try to get the parent of a file.
--
Manfred
-
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/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:20 EST