sorry, forgot to send to list again

---------- Forwarded message ----------
From: Chen Zheng <nkch...@gmail.com>
Date: 2008/11/13
Subject: Re: [zfs-code] How does zfs COW deal with '..' in brother directory?
To: Eddie Edwards <eddie at tinyted.net>


2008/11/12 Eddie Edwards <eddie at tinyted.net>:
> Well in the creation of a snapshot, the code now copies the *physical* block 
> pointer for the objset.
>
> Then if a live object changes, the live objset changes, but since this is 
> copy-on-write the snapshot objset still exists unchanged at the same physical 
> location.  So the live objset sees the new data and the snapshot objset sees 
> the old data.
>

aha, that's it,  blocks used by objset's 7 levels object number tree
have no problems of backtracking 'parent' pointer, it's quite
reasonable and feasible to using copy-on-write.


> But at snapshot creation, the objset does not need to be copied.
>
> In principle, I think you're right, in that an objset could hold both 
> versions of a file.  It would contain physical pointers to each copy.  They 
> would start out the same and diverge when one or other copy was modified.

yes, only if there are no such backtracking pointers in file tree.


maybe we can construct a version tree like this

R1 <- R2 <- R3 <- R4

 A1 <- A2 <- A3 <- A4
   ^                  ^
B   C1     <-      C2


R is the root, which has a dir A, which has dir B, C.  New versions
point to old, so old ones can be left untouched.
'parent' field in each version always point to the oldest version of
its parent, ex. C1 is born with A1, C2 is born with A3.

And another super object S points to the latest root, in this case S=R4.


1. parent '..' works fine
from R2/A2/C1/..  we get A2
from R1/A1/C1/..  we get A1

2. find objects which reference a given object directly. in this case,
C1 is referenced by A2, A1

key point is find the next version C2 which points to C1. start from
super object S, find the latest Cn, then it's easy to get C2.
Problem may be complicated when some parents of C has been deleted at
the newer versions, but it still possible to find it, just search the
next older version at the level which does not contain the desired
child entry.


3. delete object

Suppose R1, A1 are freed,  shall we free C1?  It all depends on step2,
if the only object reference C1 is A1, then just free it, or else
modify C1.parent points to A2, which is just the oldest version of its
parent now. Though we are always trying to not modify object, but here
the modification of C1.parent seems unavoidable anyway.


> For instance, zfs could support a fast "cp" which just cloned the file i.e. 
> copied the objset entry to a new objset entry.  This would allow you to copy 
> a 100GB file in milliseconds, and still have the ability to update both 
> copies of the file independently.  This is similar in principle to UNIX 
> fork().
>
> But I'm not aware of any user-level interfaces that would allow this to 
> happen.
> --
> This message posted from opensolaris.org
> _______________________________________________
> zfs-code mailing list
> zfs-code at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-code
>



--
args are passed by ref, but bindings are local, variables are in fact
just a symbol referencing an object



-- 
args are passed by ref, but bindings are local, variables are in fact
just a symbol referencing an object

Reply via email to