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>
