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]

Message-Id: <1218805256.15342.484.camel@think.oraclecorp.com>
Date:	Fri, 15 Aug 2008 09:00:56 -0400
From:	Chris Mason <chris.mason@...cle.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	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 03:39 +0200, Andi Kleen wrote:
> > The async worker threads should be spreading the load across CPUs pretty
> > well, and even a single CPU could keep up with 100MB/s checksumming.
> > But, the async worker threads do randomize the IO somewhat because the
> > IO goes from pdflush -> one worker thread per CPU -> submit_bio.  So,
> > maybe that 3rd thread is more than the drive can handle?
> 
> You have more threads with duplication? 
> 

It was a very confusing use of the word thread.  I have the same number
of kernel threads running, but the single spindle on the drive has to
deal with 3 different streams of writes.  The seeks/sec portion of the
graph shows a big enough increase in seeks on the duplication run to
explain the performance.

> > btrfsck tells me the total size of the btree is only 20MB larger with
> > checksumming on.
> > 
> > > > Btrfs no duplication            76.83 MB/s
> > > > Btrfs no dup no csum no inline  76.85 MB/s
> > > 
> > > But without duplication they are basically free here at least
> > > in IO rate. Seems odd?
> > > 
> > > Does it compute them twice in the duplication case perhaps?
> > > 
> > 
> > The duplication happens lower down in the stack, they only get done
> > once.
> 
> Ok was just speculation. The big difference still seems odd.

It does, I'll give the test a shot on other hardware too.  To be honest
I'm pretty happy at matching ext4 with duplication on.  The graph shows
even writeback and the times from each iteration are fairly consistent.

Ext3 and XFS score somewhere between 10-15MB/s on the same test...

-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/