I''m puzzled by the size reported for incremental zfs send|zfs receive. I''d expect the stream to be roughly the same size as the "used" blocks reported by zfs list. Can anyone explain why the stream size reported is so much larger that the used data in the source snapshots? Thanks. % zfs list -r -t snapshot mail/00 | tail -4 mail/00 at 0000.nightly 1.98M - 34.1G - mail/00 at 0400.hourly 1.67M - 34.1G - mail/00 at 0800.hourly 1.43M - 34.1G - mail/00 at 1000.hourly 0 - 34.1G - # zfs send -i mail/00 at 0000.nightly mail/00 at 0400.hourly | zfs receive -v -F mailtest/00 receiving incremental stream of mail/00 at 0400.hourly into mailtest/00 at 0400.hourly received 17.9MB stream in 4 seconds (4.49MB/sec) # zfs send -i mail/00 at 0400.hourly mail/00 at 0800.hourly | zfs receive -v -F mailtest/00 receiving incremental stream of mail/00 at 0800.hourly into mailtest/00 at 0800.hourly received 15.1MB stream in 1 seconds (15.1MB/sec) # zfs send -i mail/00 at 0800.hourly mail/00 at 1000.hourly | zfs receive -v -F mailtest/00 receiving incremental stream of mail/00 at 1000.hourly into mailtest/00 at 1000.hourly received 13.7MB stream in 2 seconds (6.86MB/sec) -- This message posted from opensolaris.org
On 08/06/09 12:19, Robert Lawhead wrote:> I''m puzzled by the size reported for incremental zfs send|zfs receive. I''d expect the stream to be roughly the same size as the "used" blocks reported by zfs list. Can anyone explain why the stream size reported is so much larger that the used data in the source snapshots? Thanks. >part of the reason is that the send stream contains a lot of records for free blocks and free objects. I''m working on a fix to the send stream format that will eliminate some of that. Lori> % zfs list -r -t snapshot mail/00 | tail -4 > mail/00 at 0000.nightly 1.98M - 34.1G - > mail/00 at 0400.hourly 1.67M - 34.1G - > mail/00 at 0800.hourly 1.43M - 34.1G - > mail/00 at 1000.hourly 0 - 34.1G - > > # zfs send -i mail/00 at 0000.nightly mail/00 at 0400.hourly | zfs receive -v -F mailtest/00 > receiving incremental stream of mail/00 at 0400.hourly into mailtest/00 at 0400.hourly > received 17.9MB stream in 4 seconds (4.49MB/sec) > > # zfs send -i mail/00 at 0400.hourly mail/00 at 0800.hourly | zfs receive -v -F mailtest/00 > receiving incremental stream of mail/00 at 0800.hourly into mailtest/00 at 0800.hourly > received 15.1MB stream in 1 seconds (15.1MB/sec) > > # zfs send -i mail/00 at 0800.hourly mail/00 at 1000.hourly | zfs receive -v -F mailtest/00 > receiving incremental stream of mail/00 at 1000.hourly into mailtest/00 at 1000.hourly > received 13.7MB stream in 2 seconds (6.86MB/sec) >
Is there perhaps a workaround for this? A way to condense the free blocks information? If not, any idea when an improvement might be implemented? We are currently suffering from incremental snapshots that refer to zero new blocks, but where incremental snapshots required over a gigabyte even after gzip''ing. -- This message posted from opensolaris.org