On Apr 22, 2010, at 4:50 AM, Edward Ned Harvey wrote:
>> From: Richard Elling [mailto:richard.ell...@gmail.com]
>>
>> Repeating my previous question in another way...
>> So how do they handle "mv home/joeuser home/moeuser" ?
>> Does that mv delete all snapshots below home/joeuser?
>> To make this work in ZFS, does this require that the mv(1)
>> command only work when the user has snapshot delete privilege?
>>
>> I fear that nothing in this thread is moving the problem closer to
>> RFE status :-(
>
> It's not a real directory. Just like the .zfs directory, it is magically
> accessible in every directory or subdirectory, without any need to mkdir or
> anything. Whenever you mv some directory to a new name, there's still a
> magical .snapshot directory inside of it, but all the contents are magically
> generated upon access, so the new .snapshot will reference the new directory
> name.
>
> It's all just a "frontend" in the filesystem. You do something like "cd
> .zfs" or "cd .snapshot" (or ls, or cp, or whatever) and the filesystem
> responds as if that were a real directory. But there are no *actual*
> contents of any actual directory of that name. The filesystem just
> generates a response for you which looks like subdirectories, but are really
> links to the appropriate stuff, and makes it simply look as if it were
> normal directories.
One last try. If you change the "real" directory structure, how are those
changes reflected in the "snapshot" directory structure?
Consider:
echo "whee" > /a/b/c/d.txt
[snapshot]
mv /a/b /a/B
What does /a/B/c/.snapshot point to? If the answer is "nothing," then I see
significantly less value in the feature.
IIRC, POSIX does not permit hard links to directories. Moving or renaming
the directory structure gets disconnected from the original because these
are relative relationships. Clearly, NetApp achieves this in some manner
which is not constrained by POSIX -- a manner which appears to be beyond
your ability to describe.
> To move closer to RFE status ... I think the description would have to be
> written in verbage pertaining to zfs which is more than I know. I can
> describe how they each work, but I can't make it technical enough to be an
> RFE for zfs.
I'm not disputing the value here, but the RFE may need something other than
ZPL. Today, NetApp might enjoy temporary advantage because their file
system does not have to be POSIX compliant and they limit the total number of
snapshots. OTOH, the only barrier for someone writing a non-POSIX file system
layer on ZFS is resources and enthusiasm (unlimited snapshots are already
available on ZFS).
-- richard
ZFS storage and performance consulting at http://www.RichardElling.com
ZFS training on deduplication, NexentaStor, and NAS performance
Las Vegas, April 29-30, 2010 http://nexenta-vegas.eventbrite.com
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
