Re: Btrfs v0.16 released

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2008-08-15 at 16:37 -0400, Chris Mason wrote:
> On Fri, 2008-08-15 at 15:59 -0400, Theodore Tso wrote:
> > On Fri, Aug 15, 2008 at 01:52:52PM -0400, Chris Mason wrote:
> > > Have you tried this one:
> > > 
> > > http://article.gmane.org/gmane.linux.file-systems/25560
> > > 
> > > This bug should cause fragmentation on small files getting forced out
> > > due to memory pressure in ext4.  But, I wasn't able to really
> > > demonstrate it with ext4 on my machine.
> > 
> > I've been able to use compilebench to see the fragmentation problem
> > very easily.
> > 
> > Annesh has been workign on it, and has some fixes that he queued up.
> > I'll have to point him at your proposed fix, thanks.  This is what he
> > came up with in the common code.  What do you think?
> > 
> 
> It sounds like ext4 would show the writeback_index bug with
> fragmentation on disk and btrfs would show it with seeks during the
> benchmark.  I was only watching the throughput numbers and not looking
> at filefrag results.
> 

I tried just the writeback_index patch and got only 4 fragmented files
on ext4 after a compilebench run.  Then I tried again and got 1200.
Seems there is something timing dependent in here ;)

By default compilebench uses 256k buffers for writing (see compilebench
-b) and btrfs_file_write will lock down up to 512 pages at a time during
a single write.  This means that for most small files, compilebench will
send the whole file down in one write() and btrfs_file_write will lock
down pages for the entire write() call while working on it.

So, even if pdflush tries to jump in and do the wrong thing, the pages
will be locked by btrfs_file_write and pdflush will end up skipping
them.

With the generic file write routines, pages are locked one at a time,
giving pdflush more windows to trigger delalloc while a write is still
ongoing.

-chris


--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux