linux-kernel - Re: Btrfs v0.16 released

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 16 Aug 2008 14:10:10 -0400
From:	Chris Mason <chris.mason@...cle.com>
To:	Theodore Tso <tytso@....edu>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-btrfs <linux-btrfs@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: Btrfs v0.16 released

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/