From owner-freebsd-fs@FreeBSD.ORG Fri Jun 26 17:03:35 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D1D6106564A for ; Fri, 26 Jun 2009 17:03:35 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id BEA828FC14 for ; Fri, 26 Jun 2009 17:03:34 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:53704 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MKEpl-00061m-4r for freebsd-fs@freebsd.org; Fri, 26 Jun 2009 19:03:31 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 3C3E75ED8B for ; Fri, 26 Jun 2009 19:03:28 +0200 (CEST) Message-Id: <25306F0C-437C-4746-98F1-427E335AF8EB@exscape.org> From: Thomas Backman To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 26 Jun 2009 19:03:25 +0200 X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MKEpl-00061m-4r. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MKEpl-00061m-4r 34f68bb335917fae41c6c503762c9437 Subject: ZFS send/recv: weird stream size? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 17:03:35 -0000 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