Messages in this thread | | | Date | Fri, 25 Jun 2010 14:58:57 -0400 | From | Ric Wheeler <> | Subject | Re: Btrfs: broken file system design (was Unbound(?) internal fragmentation in Btrfs) |
| |
On 06/24/2010 06:06 PM, Daniel Taylor wrote: > > > >> -----Original Message----- >> From: mikefedyk@gmail.com [mailto:mikefedyk@gmail.com] On >> Behalf Of Mike Fedyk >> Sent: Wednesday, June 23, 2010 9:51 PM >> 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 >> Subject: Re: Btrfs: broken file system design (was Unbound(?) >> internal fragmentation in Btrfs) >> >> On Wed, Jun 23, 2010 at 8:43 PM, Daniel Taylor >> <Daniel.Taylor@wdc.com> 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. >> >> > As long as no object smaller than the disk block size is ever > flushed to media, and all flushed objects are aligned to the disk > blocks, there should be no real performance hit from that. > > Otherwise we end up with the damage for the ext[234] family, where > the file blocks can be aligned, but the 1K inode updates cause > the read-modify-write (RMW) cycles and and cost>10% performance > hit for creation/update of large numbers of files. > > An RMW cycle costs at least a full rotation (11 msec on a 5400 RPM > drive), which is painful. >
Also interesting is to note that you can get a significant overheard even with 0 byte length files. Path names, metadata overhead, etc can consume (depending on the pathname length) quite a bit of space per file.
Ric
| |