linux-kernel - Re: RAID-1 performance under 2.4 and 2.6

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:	Wed, 26 Mar 2008 09:25:29 +0100
From:	""J.A. Magallón"" <jamagallon@....com>
To:	Emmanuel Florac <eflorac@...ellique.com>
Cc:	Linux-Kernel <linux-kernel@...r.kernel.org>
Subject: Re: RAID-1 performance under 2.4 and 2.6

On 2008.03.26, at 09:05, Emmanuel Florac wrote:
> Le Tue, 25 Mar 2008 19:42:28 -0400 vous écriviez:
>
>> And this is what I was saying earlier, there is a trend to blame the
>> benchmark when in fact the same benchmark runs well on 2.4.
>
> As I mentioned, it looks like 2.4 actually buffers write data on  
> RAID-1
> which is inherently bad (after all if I do RAID-1 it's for the sake of
> data integrity, and write caching just counters that).

Not bad, it buffer flushing is secure. You just have 'one buffer size'
delay. If your system crashes, think it just crashed 'one buffer size'
before...

>
> However, how bad dd may be, it reflects broadly my problem : on small
> systems using software RAID, IO is overall way better with 2.4 than
> 2.6, especially NFS thruput.
> Though I can substantially enhance 2.6 performance through tweaking
> (playing with read ahead, disk queue length etc), it still lags behind
> 2.4 with defaults settings by a clear margin (10% or more).
> This isn't true - fortunately - of larger systems with 12, 24, 48  
> disks
> drives, hardware RAID, Fibre Channel and al.
>
>

But you shouldn't have to tweak anything.
Let's forget for a moment calling dd a 'benchmark'. The fact is that a
certain program (in its default behaviour, dd if=xxx of=yyy) is waaay
slower in 2.6 than in 2.4. So something has gone nuts.
The typical question is 'who cares dd ?'. And the answer: all normal
applications that just read and write, that do not use any *advise()
because they tried to be portable, that are not rewritten and fancy
optimized to take advantage of latest kernel knobs, in short, any normal
app that just fopen()s and fread()s...
Seriously, are people telling that I have to tweak my app to get the
same performance that in 2.4 ? The basic performance should be the same,
and all those knobs should let you get _better_ throughput, not just the
same. To say anything else is to hide the head on the floor...

--
J.A. Magallon <jamagallon()ono!com>     \              Software is  
like sex:
                                          \        It's better when  
it's free
Mandriva Linux release 2008.1 (Cooker) for i586

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