> Marcelo, Hello there... > > I did some more tests. You are getting very useful informations with your tests. Thanks a lot!!
> > I found that not each uberblock_update() is also > followed by a write to > the disk (although the txg is increased every 30 > seconds for each of the > three zpools of my 2008.11 system). In these cases, > ub_rootbp.blk_birth > stays at the same value while txg is incremented by > 1. Are you sure about that? I mean, what i could understand for the ondiskformat, is that there is a correlation 1:1 between txg, creation time, and ubberblock. Each time there is write to the pool, we have another "state" of the filesystem. Actually, we just need another valid uberblock when we change the filesystem state (write to it). > > But each sync command on the OS level is followed by > a > vdev_uberblock_sync() directly after the > uberblock_update() and then by > four writes to the four uberblock copies (one per > copy) on disk. Hmm, maybe the uberblock_update is not really important in our discussion... ;-) > And a change to one or more files in any pool during > the 30 seconds > interval is also followed by a vdev_uberblock_sync() > of that pool at the > end of the interval. So, what is the uberblock_update? > > So on my system (a web server) during time when there > is enough activity > that each uberblock_update() is followed by > vdev_uberblock_sync(), > > I get: > 2 writes per minute (*60) I'm totally lost... 2 writes per minute? > writes per hour (*24) > 2880 writes per day > ut only each 128th time to the same block -> > = 22.5 writes to the same block on the drive per day. > > If we take the lower number of max. writes in the > referenced paper which > is 10.000, we get 10.000/22.5 = 444.4 days or one > year and 79 days. > > For 100.000, we get 4444.4 days or more than 12 > years. Ok, but i think the number is 10.000. 100.000 would be a static wear leveling, and it is a non-trivial implementation for USB pen drives right? > > During times without http access to my server, only > about each 5th to > 10th uberblock_update() is followed by > vdev_uberblock_sync() for rpool, > and much less for the two data pools, which means > that the corresponding > uberblocks on disk will be skipped for writing (if I > did not overlook > anything), and the device will likely be worn out > later. I need to know what is the uberblock_update... it seems not related with txg, sync of disks, labels, nothing... ;-) Thanks a lot Bernd. Leal [http://www.eall.com.br/blog] > > Regards, > > Bernd > > Marcelo Leal wrote: > > Hello Bernd, > > Now i see your point... ;-) > > Well, following a "very simple" math: > > > > - One txg each 5 seconds = 17280/day; > > - Each txg writing 1MB (L0-L3) = 17GB/day > > > > In the paper the math was 10 years = ( 2.7 * the > size of the USB drive) writes per day, right? > > So, in a 4GB drive, would be ~10GB/day. Then, just > the labels update would make our USB drive live for 5 > years... and if each txg update 5MB of data, our > drive would live for just a year. > > Help, i'm not good with numbers... ;-) > > > > Leal > > [http://www.eall.com.br/blog] > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discu > ss -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
