zfs code - Nov 2008 - How does zfs COW deal with ''..'' in brother directory? [C1]

According

2008/11/12 Matthew Ahrens <Matthew.Ahrens at sun.com>:



Yes, understood, the old A and the new A just have the same object
number N: first alloc a new block,  write new A,  then modify objset''s
slot N to let it point the new A, done


But modification of  slot N cannot be done  straighforward , it has also 
to comply  COW rules, I mean from my understanding , a new metadnode array 
is created for that objectset identical to the former one except for slot 
N (where object that had been modified lie ) . And this process goes up to 
the uberblock  , Am I right?? 


Does that mean that the two versions of A can''t both exist in the same
objset?  And snapshot S which contains old A and current active fs
which contains new A,  must have independent objsets? So when creating
snapshots, objset of the fs should be cloned.  But in
dsl_dataset_snapshot_sync,  I found that
        dsphys->ds_bp = ds->ds_phys->ds_bp;
shows that newly created snapshot has a objset same as the fs,  where
is the clone work?  And if the objset is large, has millions of slots,
that will be lots of work to do.

I''m considering if backtracking pointer like ''parent''
is allowed,  is
it still possibles that different versions of object can exist in the
same object set with different object numbers?

Matt, Eddie, thanks for your kindly help



*************************************************************************
This message and any attachments (the "message") are confidential,
intended solely for the addressee(s), and may contain legally privileged
information.
Any unauthorised use or dissemination is prohibited. E-mails are susceptible to
alteration.
Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be
liable for the message if altered, changed or
falsified.
                              ************
Ce message et toutes les pieces jointes (ci-apres le "message") sont
confidentiels et susceptibles de contenir des informations couvertes
par le secret professionnel. 
Ce message est etabli a l''intention exclusive de ses destinataires.
Toute utilisation ou diffusion non autorisee est interdite.
Tout message electronique est susceptible d''alteration. 
La SOCIETE GENERALE et ses filiales declinent toute responsabilite au titre de
ce message s''il a ete altere, deforme ou falsifie.
*************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-code/attachments/20081113/06ac3a6b/attachment.html>

2008/11/13 Cyril ROUHASSIA <cyril.rouhassia at
sgcib.com>:
>
> According
>
> 2008/11/12 Matthew Ahrens <Matthew.Ahrens at sun.com>:
>
>
>
> Yes, understood, the old A and the new A just have the same object
> number N: first alloc a new block,  write new A,  then modify
objset''s
> slot N to let it point the new A, done
>
>
> But modification of  slot N cannot be done  straighforward , it has also to
> comply  COW rules, I mean from my understanding , a new metadnode array is
> created for that objectset identical to the former one except for slot N
> (where object that had been modified lie ) . And this process goes up to
the
> uberblock  , Am I right??
>
Yes,  you need to copy the block first which holds slot N,  modify it
and any necessary upper blocks in the object number index tree rooted
at blkptr of objset dnode,  then keep going up until you get the
uberblock.


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

Hi,
to be very understandable for me, it is not  only  slot N which is  COWed 
but the *WHOLE*  1024  entries array (metadnode structure) which is COWed 
because COW applies only on blocks pointed by block pointer structure  am 
i right???
Cheers
C  Rouhassia



"Chen Zheng" <nkchenz at gmail.com> 
14/11/08 03:37


To
Cyril ROUHASSIA/fr/socgen at socgen
cc
zfs-code at opensolaris.org
Subject
Re: [zfs-code] How does zfs COW deal with ''..'' in brother
directory? [C1]






2008/11/13 Cyril ROUHASSIA <cyril.rouhassia at
sgcib.com>:
>
> According
>
> 2008/11/12 Matthew Ahrens <Matthew.Ahrens at sun.com>:
>
>
>
> Yes, understood, the old A and the new A just have the same object
> number N: first alloc a new block,  write new A,  then modify
objset''s
> slot N to let it point the new A, done
>
>
> But modification of  slot N cannot be done  straighforward , it has also 
to
> comply  COW rules, I mean from my understanding , a new metadnode array 
is
> created for that objectset identical to the former one except for slot N
> (where object that had been modified lie ) . And this process goes up to 
the
> uberblock  , Am I right??
>
Yes,  you need to copy the block first which holds slot N,  modify it
and any necessary upper blocks in the object number index tree rooted
at blkptr of objset dnode,  then keep going up until you get the
uberblock.


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

*************************************************************************
This message and any attachments (the "message") are confidential,
intended solely for the addressee(s), and may contain legally privileged
information.
Any unauthorised use or dissemination is prohibited. E-mails are susceptible to
alteration.
Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be
liable for the message if altered, changed or
falsified.
                              ************
Ce message et toutes les pieces jointes (ci-apres le "message") sont
confidentiels et susceptibles de contenir des informations couvertes
par le secret professionnel. 
Ce message est etabli a l''intention exclusive de ses destinataires.
Toute utilisation ou diffusion non autorisee est interdite.
Tout message electronique est susceptible d''alteration. 
La SOCIETE GENERALE et ses filiales declinent toute responsabilite au titre de
ce message s''il a ete altere, deforme ou falsifie.
*************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-code/attachments/20081114/d12eac0d/attachment.html>