From owner-freebsd-fs@FreeBSD.ORG Tue Jan 29 10:58:06 2013 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E4422AC2 for ; Tue, 29 Jan 2013 10:58:06 +0000 (UTC) (envelope-from prvs=1741a054e2=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 87E82F8C for ; Tue, 29 Jan 2013 10:58:06 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50001906002.msg for ; Tue, 29 Jan 2013 10:57:58 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 29 Jan 2013 10:57:58 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1741a054e2=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: fs@freebsd.org Message-ID: <2FD375DC62B24754B8945BF0A1E26B78@multiplay.co.uk> From: "Steven Hartland" To: "Adam Nowacki" , "Matthew Ahrens" References: <5105252D.6060502@platinum.linux.pl> <5107A9B7.5030803@platinum.linux.pl> Subject: Re: RAID-Z wasted space - asize roundups to nparity +1 Date: Tue, 29 Jan 2013 10:58:40 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response 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 Cc: fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 10:58:07 -0000 ----- Original Message ----- From: "Adam Nowacki" > On 2013-01-28 22:55, Matthew Ahrens wrote: >> This is so that we won't end up with small, unallocatable segments. >> E.g. if you are using RAIDZ2, the smallest usable segment would be 3 >> sectors (1 sector data + 2 sectors parity). If we left a 1 or 2 sector >> free segment, it would be unusable and you'd be able to get into strange >> accounting situations where you have free space but can't write because >> you're "out of space". > > Sounds reasonable. > >> The amount of waste due to this can be minimized by using larger >> blocksizes (e.g. the default recordsize of 128k and files larger than >> 128k), and by using smaller sector sizes (e.g. 512b sector disks rather >> than 4k sector disks). In your case these techniques would limit the >> waste to 0.6%. > > This brings another issue - recordsize capped at 128KiB. We are using > the pool for off-line storage of large files (from 50MB to 20GB). Files > are stored and read sequentially as a whole. With 12 disks in RAID-Z2, > 4KiB sectors, 128KiB record size and the padding above 9.4% of disk > space goes completely unused - one whole disk. This is something thats being worked on upstream, its not as trivial as it first looks unfortuantely. 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.