Marcelo,
I did some more tests.
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.
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.
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 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)
= 120 writes per hour (*24)
= 2880 writes per day
but 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.
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.
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-discuss
