> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Mattias Pantzare
>
> The nfs server can find the file but not the file _name_.
>
> inode is all that the NFS server needs, it does not need the file name
> if it has the inode number.
It is not useful or helpful for you guys to debate whether or not this is
possible. And it is especially not helpful to flat out say "it's not
possible." Here is the final word on whether or not it's possible:
Whenever any process calls "open('/some/path/filename')" that system call is
handled by the kernel, recursively resolving name to inode number, checking
permissions, and opening that inode number, until the final inode is
identified and opened, or some error is encountered. The point is:
Obviously, the kernel has the facility to open an inode by number. However,
for security reasons (enforcing permissions of parent directories before the
parent directories have been identified), the ability to open an arbitrary
inode by number is not normally made available to user level applications,
except perhaps when run by root.
At present, a file inode does not contain any reference to its parent
directory or directories. But that's just a problem inherent to files. It
is fundamentally easier to reverse lookup a directory by inode number,
because this information is already in the filesystem. No filesystem
enhancements are needed to reverse lookup a directory by inode number,
because: (a) every directory contains an entry ".." which refers to its
parent by number, and (b) every directory has precisely one parent, and no
more. There is no such thing as a hardlink copy of a directory. Therefore,
there is exactly one absolute path to any directory in any ZFS filesystem.
If the kernel (or root) can open an arbitrary directory by inode number,
then the kernel (or root) can find the inode number of its parent by looking
at the '..' entry, which the kernel (or root) can then open, and identify
both: the name of the child subdir whose inode number is already known, and
(b) yet another '..' entry. The kernel (or root) can repeat this process
recursively, up to the root of the filesystem tree. At that time, the
kernel (or root) has completely identified the absolute path of the inode
that it started with.
The only question I want answered right now is:
Although it is possible, is it implemented? Is there any kind of function,
or existing program, which can be run by root, to obtain either the complete
path of a directory by inode number, or to simply open an inode by number,
which would leave the recursion and absolute path generation yet to be
completed?
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
