From owner-freebsd-questions@FreeBSD.ORG Tue May 14 04:11:01 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E5AC4BCE for ; Tue, 14 May 2013 04:11:01 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by mx1.freebsd.org (Postfix) with ESMTP id 72741F17 for ; Tue, 14 May 2013 04:11:01 +0000 (UTC) Received: from ppp247-71.static.internode.on.net (HELO leader.local) ([203.122.247.71]) by ipmail07.adl2.internode.on.net with ESMTP; 14 May 2013 13:40:58 +0930 Message-ID: <5191B950.4040402@ShaneWare.Biz> Date: Tue, 14 May 2013 13:40:56 +0930 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Subject: Re: ZFS mirror install /mnt is empty References: <5190058D.2030705@micite.net> <472E17AF-B249-4FD3-8F5E-716F8B7867F5@kraus-haus.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Paul Kraus , "freebsd-questions@freebsd.org List" X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 04:11:02 -0000 > On Mon, 13 May 2013 08:40-0400, Paul Kraus wrote: >> On May 13, 2013, at 1:58 AM, Trond Endrestøl wrote: >>> Due to advances in hard drive technology, for the worse I'm >>> afraid, i.e. 4K disk blocks, I wouldn't bother enabling >>> compression on any ZFS file systems. I might change my blog posts >>> to reflect this stop gap. > I guess it's due to my (mis)understanding that files shorter than > 4KB stored on 4K drives never will be subject to compression. And as > you state below, the degree of compression depends largely on the > data at hand. I don't want to start a big discussion but want to express an opinion that others may think about. When it comes to disk compression I think people overlook the fact that it can impact on more than one level. The size of disks these days means that compression doesn't make a big difference to storage capacity for most people and 4k blocks mean little change in final disk space used. One thing people seem to miss is the fact that compressed files are going to reduce the amount of data sent through the bottle neck that is the wire between motherboard and drive. While a 3k file compressed to 1k still uses a 4k block on disk it does (should) reduce the true data transferred to disk. Given a 9.1 source tree using 865M, if it compresses to 400M then it is going to reduce the time to read the entire tree during compilation. This would impact a 32 thread build more than a 4 thread build. While it is said that compression adds little overhead, time wise, it is going to take time to compress the data which is going to increase latency. Going from a 6ms platter disk latency to a 0.2ms SSD latency gives a noticeable improvement to responsiveness. Adding compression is going to bring that back up - possibly higher than 6ms. Together these two factors may level out the total time to read a file. One question there is whether the zfs cache uses compressed file data therefore keeping the latency while eliminating the bandwidth. Personally I have compression turned off (desktop). My thought is that the latency added for compression would negate the bandwidth savings. For a file server I would consider turning it on as network overhead is going to hide the latency.