From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Fedyk Subject: Re: Btrfs: broken file system design (was Unbound(?) internal fragmentation in Btrfs) Date: Wed, 23 Jun 2010 21:51:12 -0700 Message-ID: References: <4C07C321.8010000@redhat.com> <4C1B7560.1000806@gmail.com> <4C1BA3E5.7020400@gmail.com> <20100623234031.GF7058@shareable.org> <469D2D911E4BF043BFC8AD32E8E30F5B24AEBA@wdscexbe07.sc.wdc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Daniel J Blueman , Mat , LKML , linux-fsdevel@vger.kernel.org, Chris Mason , Ric Wheeler , Andrew Morton , Linus Torvalds , The development of BTRFS To: Daniel Taylor Return-path: In-Reply-To: <469D2D911E4BF043BFC8AD32E8E30F5B24AEBA@wdscexbe07.sc.wdc.com> List-ID: On Wed, Jun 23, 2010 at 8:43 PM, Daniel Taylor = wrote: > Just an FYI reminder. =C2=A0The original test (2K files) is utterly > pathological for disk drives with 4K physical sectors, such as > those now shipping from WD, Seagate, and others. =C2=A0Some of the > SSDs have larger (16K0 or smaller blocks (2K). =C2=A0There is also > the issue of btrfs over RAID (which I know is not entirely > sensible, but which will happen). > > The absolute minimum allocation size for data should be the same > as, and aligned with, the underlying disk block size. =C2=A0If that > results in underutilization, I think that's a good thing for > performance, compared to read-modify-write cycles to update > partial disk blocks. Block size =3D 4k Btrfs packs smaller objects into the blocks in certain cases. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751787Ab0FXEvR (ORCPT ); Thu, 24 Jun 2010 00:51:17 -0400 Received: from mail-vw0-f46.google.com ([209.85.212.46]:53272 "EHLO mail-vw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751340Ab0FXEvP convert rfc822-to-8bit (ORCPT ); Thu, 24 Jun 2010 00:51:15 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=vukcV6z25uS7KJnWQ4HIAazVOePLUM5R5EihX2Pm5icShmNjz/xNjf8tJPmpS3dVVK cEQLTYQKPtgXXh9zz3osz7hgNRL+ltmB6+5gE/a1Pixe7ymbvrto9sion1fhUCT/Jdkn fzPXHa4VJTxRHEWQTprLfgyoS/likGywSBKb8= MIME-Version: 1.0 In-Reply-To: <469D2D911E4BF043BFC8AD32E8E30F5B24AEBA@wdscexbe07.sc.wdc.com> References: <4C07C321.8010000@redhat.com> <4C1B7560.1000806@gmail.com> <4C1BA3E5.7020400@gmail.com> <20100623234031.GF7058@shareable.org> <469D2D911E4BF043BFC8AD32E8E30F5B24AEBA@wdscexbe07.sc.wdc.com> Date: Wed, 23 Jun 2010 21:51:12 -0700 X-Google-Sender-Auth: vCFeQOXcPfSYMeyHUrw5YoT5UOg Message-ID: Subject: Re: Btrfs: broken file system design (was Unbound(?) internal fragmentation in Btrfs) From: Mike Fedyk To: Daniel Taylor Cc: Daniel J Blueman , Mat , LKML , linux-fsdevel@vger.kernel.org, Chris Mason , Ric Wheeler , Andrew Morton , Linus Torvalds , The development of BTRFS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 23, 2010 at 8:43 PM, Daniel Taylor wrote: > Just an FYI reminder.  The original test (2K files) is utterly > pathological for disk drives with 4K physical sectors, such as > those now shipping from WD, Seagate, and others.  Some of the > SSDs have larger (16K0 or smaller blocks (2K).  There is also > the issue of btrfs over RAID (which I know is not entirely > sensible, but which will happen). > > The absolute minimum allocation size for data should be the same > as, and aligned with, the underlying disk block size.  If that > results in underutilization, I think that's a good thing for > performance, compared to read-modify-write cycles to update > partial disk blocks. Block size = 4k Btrfs packs smaller objects into the blocks in certain cases. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Fedyk Subject: Re: Btrfs: broken file system design (was Unbound(?) internal fragmentation in Btrfs) Date: Wed, 23 Jun 2010 21:51:12 -0700 Message-ID: References: <4C07C321.8010000@redhat.com> <4C1B7560.1000806@gmail.com> <4C1BA3E5.7020400@gmail.com> <20100623234031.GF7058@shareable.org> <469D2D911E4BF043BFC8AD32E8E30F5B24AEBA@wdscexbe07.sc.wdc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Daniel J Blueman , Mat , LKML , linux-fsdevel@vger.kernel.org, Chris Mason , Ric Wheeler , Andrew Morton , Linus Torvalds , The development of BTRFS To: Daniel Taylor Return-path: In-Reply-To: <469D2D911E4BF043BFC8AD32E8E30F5B24AEBA@wdscexbe07.sc.wdc.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Jun 23, 2010 at 8:43 PM, Daniel Taylor = wrote: > Just an FYI reminder. =C2=A0The original test (2K files) is utterly > pathological for disk drives with 4K physical sectors, such as > those now shipping from WD, Seagate, and others. =C2=A0Some of the > SSDs have larger (16K0 or smaller blocks (2K). =C2=A0There is also > the issue of btrfs over RAID (which I know is not entirely > sensible, but which will happen). > > The absolute minimum allocation size for data should be the same > as, and aligned with, the underlying disk block size. =C2=A0If that > results in underutilization, I think that's a good thing for > performance, compared to read-modify-write cycles to update > partial disk blocks. Block size =3D 4k Btrfs packs smaller objects into the blocks in certain cases.