On Apr 24, 2010, at 2:17 PM, Ragnar Sundblad wrote:
> On 24 apr 2010, at 16.43, Richard Elling wrote:
>
>> I do not recall reaching that conclusion. I think the definition of the
>> problem
>> is what you continue to miss.
>
> Me too then, I think. Can you please enlighten us about the
> definition of the problem?
Last chance.
>>> The .snapshot directories do precisely what you would want them to do.
>>> Which is: The .snapshot directory belonging to a parent contains a copy of
>>> the filesystem as it looked at the time of the snapshot. But when you mv or
>>> rename a subdirectory, then the .snapshot subdir of the subdirectory
>>> correctly maps, to preserve the snapshots inside that directory.
>>
>> Agree, but the path is lost.
>
> In what way?
>
> On 24 apr 2010, at 09.18, Brandon High wrote:
>> To answer the question you linked to:
>> .shapshot/snapname.0/a/b/c/d.txt from the top of the filesystem
>> a/.snapshot/snapname.0/b/c/d.txt
>> a/e/.shapshot/snapname.0/c/d.txt
>> a/e/c/.snapshot/snapname.0/d.txt
>
> I really don't understand what you mean, I think the path is there
> just fine, and IMHO pretty much in the way you would expect.
Next,
mv /a/e /a/E
ls -l a/e/.snapshot/snaptime
ENOENT?
ls -l a/E/.snapshot/snapname/d.txt
this should be ENOENT because d.txt did not exist in a/E at snaptime.
-- 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
