On Wed, Apr 28, 2010 at 09:49:04PM +0200, Ragnar Sundblad wrote:
> On 28 apr 2010, at 14.06, Edward Ned Harvey wrote:
> 
> What indicators do you have that ONTAP/WAFL has inode->name lookup
> functionality? I don't think it has any such thing - WAFL is pretty
> much an UFS/FFS that does COW instead of in-place writing, the main
> difference is that inodes are written to special inode files rather
> than specific static areas. Directories I believe works very much like
> UFS/FFS directories. But I may have misunderstood something and be
> wrong.

You're correct that the FS is very UFS/FFS, but they've added stuff.
The inode->name lookup is a bolt-on feature that was added in 7.1 (and
can be disabled).

# touch /net/tester/vol/ntap/file
# ls -li /net/tester/vol/ntap/file
    307107 -rw-r--r--   1 root     other          0 Apr 30 13:35 
/net/tester/vol/ntap/file

tester*> inodepath -v ntap -a 307107
Inode 307107 in volume ntap (fsid 0x29428a) has 1 name.
Volume UUID is: 588b6ef0-5231-11de-9885-00a09800f026
[    1] Primary pathname = /vol/ntap/file

In general it is an internal feature and not readily exposed for user
operations.  I've seen it mentioned that it's very handy for their
interaction with virus scanners so it can pass a full path back to
them.  Also it helps with error messages.

It's not really exposed via file ops.  The only time I've ever used it
directly was when one of my servers was getting beaten up by clients.
The only diags were to scan the network and then go from the NFS FH to a
filename.  With ZFS on Solaris, I'm assuming that wouldn't be necessary
because you'd have dtrace to tell you exactly what files were being
accessed.

-- 
Darren
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to