Dear all,
please find below test that I have run:
#zdb -vuuuu unxtmpzfs3 <--------------uberblock for unxtmpzfs3 spool
Uberblock
magic = 0000000000bab10c
version = 4
txg = 86983
guid_sum = 9860489793107228114
timestamp = 1225183041 UTC = Tue Oct 28 09:37:21 2008
rootbp = [L0 DMU objset] 400L/200P DVA[0]=<1:80000:200>
DVA[1]=<0:7ac00:200> DVA[2]=<1:18013000:200> fletcher4 lzjb BE
contiguous
birth=86983 fill=38
cksum=d7e4c6e6f:508f5121f9f:f66339b469f2:2025284ff2f12d
# echo titi >> /unxtmpzfs3/mnt1/mnt4/te1 <------------------ update of
te1
file located in the zpool
# zdb -vuuuu unxtmpzfs3 <------------------ uberblock for unxtmpzfs3
spool after file update
Uberblock
magic = 0000000000bab10c
version = 4
txg = 87012
guid_sum = 9860489793107228114
timestamp = 1225183186 UTC = Tue Oct 28 09:39:46 2008
rootbp = [L0 DMU objset] 400L/200P DVA[0]=<1:82a00:200>
DVA[1]=<0:7e400:200> DVA[2]=<1:18015c00:200> fletcher4 lzjb BE
contiguous
birth=87012 fill=38
cksum=c3ac8e047:46e375e1c21:d272d39402da:1aaadb02468e54
Conclusion is:
Because of one change to just one file, the MOS is a brend new one. Then
the question is :
Is the new MOS a whole copy of the previous one or does it share
untouched data with the previous one and has its own copy of specific data
(like an update onto a regular file)?
Indeed, I have checked the metadnode array entries and it sounds like
there are few entries which are different .
Is the uperblock a brend new one after the update (just 128k possible
uperblocks!!!)??
Thank for your answer
C Rouhassia
*************************************************************************
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-discuss/attachments/20081028/b959a964/attachment.html>
Hi Cyril, Cyril ROUHASSIA wrote:> > Dear all, > please find below test that I have run: > > #zdb -vuuuu unxtmpzfs3 <--------------uberblock for unxtmpzfs3 spool > Uberblock > > magic = 0000000000bab10c > version = 4 > txg = 86983 > guid_sum = 9860489793107228114 > timestamp = 1225183041 UTC = Tue Oct 28 09:37:21 2008 > rootbp = [L0 DMU objset] 400L/200P DVA[0]=<1:80000:200> > DVA[1]=<0:7ac00:200> DVA[2]=<1:18013000:200> fletcher4 lzjb BE > contiguous birth=86983 fill=38 > cksum=d7e4c6e6f:508f5121f9f:f66339b469f2:2025284ff2f12d > > > # echo titi >> /unxtmpzfs3/mnt1/mnt4/te1 <------------------ update of > te1 file located in the zpool > > # zdb -vuuuu unxtmpzfs3 <------------------ uberblock for > unxtmpzfs3 spool after file update > Uberblock > > magic = 0000000000bab10c > version = 4 > txg = 87012 > guid_sum = 9860489793107228114 > timestamp = 1225183186 UTC = Tue Oct 28 09:39:46 2008 > rootbp = [L0 DMU objset] 400L/200P DVA[0]=<1:82a00:200> > DVA[1]=<0:7e400:200> DVA[2]=<1:18015c00:200> fletcher4 lzjb BE > contiguous birth=87012 fill=38 > cksum=c3ac8e047:46e375e1c21:d272d39402da:1aaadb02468e54 > > > > Conclusion is: > > * Because of one change to just one file, the MOS is a brend new > one. Then the question is : > > Is the new MOS a whole copy of the previous one or does it share > untouched data with the previous one and has its own copy of specific > data (like an update onto a regular file)? > Indeed, I have checked the metadnode array entries and it sounds like > there are few entries which are different .A block containing changed MOS data will be new. Other blocks of the MOS should be unchanged. Of course, any indirect (gang) blocks that need to be updated will also be new.> > * Is the uperblock a brend new one after the update (just 128k > possible uperblocks!!!)?? >Only one is "active" at any one time. As I recall, the 128 possible uberblocks are treated as a circular array. max
> Because of one change to just one file, the MOS is a brend new oneYes, "all writes in ZFS are done in transaction groups".. so, evertime there is a commit, something is really write to disk, there is a new txg and all the blocks written are related to that txg (even the ubberblock). I don?t know if i understood the other questions about updates in the MOS, 128K uberblocks, and regular files... but the location of the active uberblock is on the vdev?s labels (L0...L3), and the label?s update is the only one is not COW on ZFS, because the location of labels are fixed on disks. The updates in labels are done following "a staged approach" = (L0/L2 after L1/L3). And the "updates to an uberblock are done by writing a modified uberblock to another element of the uberblock array(128)". peace. Leal -- This message posted from opensolaris.org