when and how is fop_space function called?
What is the system call trace? Actually wanted to get the flow of system calls
generated for the function call zfs_space. Have traced it back till
fop_space(or vop_space?)
Can anyone please explain?
Thanks in advance.
--
This message posted from opensol
2008/11/12 Matthew Ahrens :
> Chen Zheng wrote:
>>
>> Hi matt,
>>
>> I have some problems about understanding zfs COW implemention. Suppose
>> b and c are both children dir of a, if c changes, there will be new
>> versions of both a and c, namely c' and a'.
>>
>> a a'
>> b c c'
>>
>
> Actually
Eddie Edwards wrote:
> When compiling the Solaris AVL and zfs DMU modules on Windows I get many
> warnings where a uintptr_t is cast to an int, and vice versa. The actual
> cases seem benign (e.g. AVL is doing unitptr_t & 1 -> int, which is OK) but
> I'm worried there might be some real issues.
Interesting. In fact I just found a thread on this exact idea here:
http://www.opensolaris.org/jive/thread.jspa?threadID=41615&tstart=90
--
This message posted from opensolaris.org
Eddie Edwards wrote:
> 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.
>
> For instance, zfs could support a fast "cp" wh
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
Many thanks.
--
This message posted from opensolaris.org
When compiling the Solaris AVL and zfs DMU modules on Windows I get many
warnings where a uintptr_t is cast to an int, and vice versa. The actual cases
seem benign (e.g. AVL is doing unitptr_t & 1 -> int, which is OK) but I'm
worried there might be some real issues.
Just for my sanity, is "int
