From owner-freebsd-stable@FreeBSD.ORG Sat Mar 2 23:13:07 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F00ABA17 for ; Sat, 2 Mar 2013 23:13:07 +0000 (UTC) (envelope-from prvs=1773e84f73=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 7027D887 for ; Sat, 2 Mar 2013 23:13:06 +0000 (UTC) Received: from r2d2 ([46.65.172.4]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50002492112.msg for ; Sat, 02 Mar 2013 23:13:06 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 02 Mar 2013 23:13:06 +0000 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 46.65.172.4 X-Return-Path: prvs=1773e84f73=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <2B3286B0A0354074824503C06E5D17D2@multiplay.co.uk> From: "Steven Hartland" To: "Karl Denninger" , References: <20130301165040.GA26251@anubis.morrow.me.uk> <20130301185912.GA27546@anubis.morrow.me.uk> <20130302221446.GG286@server.rulingia.com> <513283BC.5090606@denninger.net> Subject: Re: Musings on ZFS Backup strategies Date: Sat, 2 Mar 2013 23:12:56 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 23:13:08 -0000 ----- Original Message ----- From: "Karl Denninger" > Reality however is that the on-disk format of most database files is > EXTREMELY compressible (often WELL better than 2:1), so I sacrifice > there. I think the better option is to stuff a user parameter into the > filesystem attribute table (which apparently I can do without boundary) > telling the script whether or not to compress on output so it's not tied > to the filesystem's compression setting. > > I'm quite-curious, in fact, as to whether the "best practices" really > are in today's world. Specifically, for a CPU-laden machine with lots > of compute power I wonder if enabling compression on the database > filesystems and leaving the recordsize alone would be a net performance > win due to the reduction in actual I/O volume. This assumes you have > the CPU available, of course, but that has gotten cheaper much faster > than I/O bandwidth has. We've been using ZFS compression on mysql filesystems for quite some time and have good success with it. It is dependent on the HW as you say though so you need to know where the bottleneck is in your system, cpu or disk. mysql 5.6 also added better recordsize support which could be interesting. Also be aware of the additional latency the compression can add. I'm also not 100% sure that the compression in ZFS scales beyond one core its been something I've meant to look in to / test but not got round to. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk.