Date: Fri, 26 Jun 2009 19:03:25 +0200 From: Thomas Backman <serenity@exscape.org> To: freebsd-fs@freebsd.org Subject: ZFS send/recv: weird stream size? Message-ID: <25306F0C-437C-4746-98F1-427E335AF8EB@exscape.org>
next in thread | raw e-mail | index | archive | help
Hi all, First off: not subscribed, please make sure I'm cc:ed or such. I found a minor oddity today when running my backup script. It copies a pool into another, using "zfs send -R -I $LASTSNAP tank@$CURRSNAP | zfs recv -Fvd slave" (the variables should explain themselves). Anyway, I got this in the middle: receiving incremental stream of tank/var/crash@backup-20090626-1505 into slave/var/crash@backup-20090626-1505 received 1.28GB stream in 51 seconds (25.6MB/sec) tank/var/crash is a compressed filesystem, using lzjb. Now, the only notable change in var/crash between backups was the addition of vmcore.22: [root@chaos /var/crash]# du -sch *22* 33K core.txt.22 1.0K info.22 34M kernel.debug.22 459M vmcore.22 493M total [root@chaos /var/crash]# du -schA *22* 88K core.txt.22 512B info.22 57M kernel.debug.22 2.2G vmcore.22 2.3G total So, if the new files' compressed size is 493MB, and the real size is 2.3GB, how come zfs send/recv transfers 1.28 GB? Other, possibly interesting (although I doubt it) stats: [root@chaos ~]# zfs get compress,compressratio tank/var/crash NAME PROPERTY VALUE SOURCE tank/var/crash compression lzjb local tank/var/crash compressratio 2.90x - [root@chaos ~]# du -shc /var/crash 1.0G /var/crash 1.0G total [root@chaos ~]# du -shcA /var/crash 6.9G /var/crash 6.9G total Regards, Thomas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25306F0C-437C-4746-98F1-427E335AF8EB>