On 25 apr 2010, at 20.12, Richard Elling wrote:
> On Apr 25, 2010, at 5:45 AM, Edward Ned Harvey wrote:
>
>>> From: Richard Elling [mailto:richard.ell...@gmail.com]
>>> Sent: Saturday, April 24, 2010 7:42 PM
>>>
>>> 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.
>>
>> Incorrect.
>>
>> E did exist. Inode 12345 existed, but it had a different name at the time
>> of snapshot. Therefore,
>> a/e/.snapshot/snapname/c/d.txt is the file at the time of snapshot.
>> But these are also the same thing:
>> a/E/.snapshot/snapname/c/d.txt
>> a/E/c/.snapshot/snapname/d.txt
>
> OK, I'll believe you.
>
> How about this?
>
> mv a/E/c a/c
> mv a/E a/c
> mv a/c a/E
>
> now a/E/.snapshot/snapname/c/d.txt is ENOENT, correct?
Sadly I can't test it myself right now, maybe someone else can,
but I'd except:
[start: we have a file: a/E/c/d.txt]
[snap1]
mv a/E/c a/c
[snap2]
mv a/E a/c
mv a/c a/E
would result in:
a/.snapshot/snap1/E/c/d.txt
a/.snapshot/snap2/E/ (empty)
a/.snapshot/snap2/c/d.txt
a/E/.snapshot/snap1/c/d.txt
a/E/.snapshot/snap2/ (empty)
a/E/ (empty)
Wouldn't that be logical, and what would be the problem?
>> It would be very annoying if you could have a directory named "foo" which
>> contains all the snapshots for its own history, and then "mv foo bar" and
>> suddenly the snapshots all disappear. This is not the behavior.
>>
>> The behavior is: If you "mv foo bar" then the snapshots which were
>> previously accessible under foo are now accessible under bar. However, if
>> you look in the snapshot of foo's parent, then you will see "foo" and not
>> "bar". Just the way it would have looked, at the time of the snapshot.
>>
>
> The only way I know to describe this is that the path is lost.
> In other words, you cannot say ../.snapshot/snapname/self is the same as
> self/.snapshot/snapname, thus the relationship previously described as:
>
> Snapshots are taken. You can either file.txt via any of the following:
> /root/.snapshot/branch/leaf/file.txt
> /root/branch/.snapshot/leaf/file.txt
> /root/branch/leaf/.snapshot/file.txt
>
> is not guaranteed to be correct.
No, not if the hierarchy is changed between the snapshots, I think
it was just a way to illustrate how the .snapshot directories work.
It isn't in zfs either, if the example above would be a zfs, we would
have:
a/.zfs/snapshot/snap1/E/c/d.txt
a/.zfs/snapshot/snap2/c/d.txt
a/E/ (empty)
I still don't understand why the OnTap model is losing more paths
than zfs.
I'd be happy if you could take one more shot at explaining.
/ragge
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
