Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933655Ab0FRPMx (ORCPT ); Fri, 18 Jun 2010 11:12:53 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]:51932 "EHLO rcsinet10.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932443Ab0FRPMv (ORCPT ); Fri, 18 Jun 2010 11:12:51 -0400 Date: Fri, 18 Jun 2010 11:10:17 -0400 From: Chris Mason To: Edward Shishkin Cc: Mat , LKML , linux-fsdevel@vger.kernel.org, Ric Wheeler , Andrew Morton , Linus Torvalds , The development of BTRFS Subject: Re: Btrfs: broken file system design (was Unbound(?) internal fragmentation in Btrfs) Message-ID: <20100618151017.GN27466@think> Mail-Followup-To: Chris Mason , Edward Shishkin , Mat , LKML , linux-fsdevel@vger.kernel.org, Ric Wheeler , Andrew Morton , Linus Torvalds , The development of BTRFS References: <4C07C321.8010000@redhat.com> <4C1B7560.1000806@gmail.com> <20100618134755.GG27466@think> <4C1B8B4A.9060308@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C1B8B4A.9060308@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Auth-Type: Internal IP X-Source-IP: rcsinet15.oracle.com [148.87.113.117] X-CT-RefId: str=0001.0A090201.4C1B8CC6.014B:SCFMA4539811,ss=1,fgs=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2825 Lines: 64 On Fri, Jun 18, 2010 at 05:05:46PM +0200, Edward Shishkin wrote: > Chris Mason wrote: > >On Fri, Jun 18, 2010 at 03:32:16PM +0200, Edward Shishkin wrote: > >>Mat wrote: > >>>On Thu, Jun 3, 2010 at 4:58 PM, Edward Shishkin wrote: > >>>>Hello everyone. > >>>> > >>>>I was asked to review/evaluate Btrfs for using in enterprise > >>>>systems and the below are my first impressions (linux-2.6.33). > >>>> > >>>>The first test I have made was filling an empty 659M (/dev/sdb2) > >>>>btrfs partition (mounted to /mnt) with 2K files: > >>>> > >>>># for i in $(seq 1000000); \ > >>>>do dd if=/dev/zero of=/mnt/file_$i bs=2048 count=1; done > >>>>(terminated after getting "No space left on device" reports). > >>>> > >>>># ls /mnt | wc -l > >>>>59480 > >>>> > >>>>So, I got the "dirty" utilization 59480*2048 / (659*1024*1024) = 0.17, > >>>>and the first obvious question is "hey, where are other 83% of my > >>>>disk space???" I looked at the btrfs storage tree (fs_tree) and was > >>>>shocked with the situation on the leaf level. The Appendix B shows > >>>>5 adjacent btrfs leafs, which have the same parent. > >>>> > >>>>For example, look at the leaf 29425664: "items 1 free space 3892" > >>>>(of 4096!!). Note, that this "free" space (3892) is _dead_: any > >>>>attempts to write to the file system will result in "No space left > >>>>on device". > > > >There are two easy ways to fix this problem. Turn off the inline > >extents (max_inline=0) or allow splitting of the inline extents. I > >didn't put in the splitting simply because the complexity was high while > >the benefits were low (in comparison with just turning off the inline > >extents). > > Hello, Chris. Thanks for response! > I afraid that both ways won't fix the problem. Look at this leaf: > > [...] > leaf 29425664 items 1 free space 3892 generation 8 owner 5 > fs uuid 50268d9d-2a53-4f4d-b3a3-4fbff74dd956 > chunk uuid 963ba49a-bb2b-48a3-9b35-520d857aade6 > item 0 key (320 XATTR_ITEM 3817753667) itemoff 3917 itemsize 78 > location key (0 UNKNOWN 0) type 8 > namelen 16 datalen 32 name: security.selinux > [...] > > There is no inline extents, and what are you going to split here? > All leafs must be at least a half filled, otherwise we loose all > boundaries, which provides non-zero utilization.. Right, there is no inline extent because we require them to fit entirely in the leaf. So we end up with mostly empty leaves because the inline item is large enough to make it difficult to push around but not large enough to fill the leaf. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/