linux-kernel - Re: HELP: Getting unexpected fakeraid behavior. Fix?

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: <9871ee5f0807061344u155db848r96863535eb00f3ce@mail.gmail.com>
Date:	Sun, 6 Jul 2008 16:44:16 -0400
From:	"Timothy Normand Miller" <theosib@...il.com>
To:	"Arjan van de Ven" <arjan@...radead.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: HELP: Getting unexpected fakeraid behavior. Fix?

On Sun, Jul 6, 2008 at 4:19 PM, Arjan van de Ven <arjan@...radead.org> wrote:

>> Since RAID1 is a mirrored configuration, it's possible to distribute
>> reads across the drives, improving throughput and latency over a
>> single drive on random reads.
>
> This is.. borderline true. Let me explain the caveats;
> for a SINGLE THREADED workload, there is actually no difference.
> Balancing long sequential reads over the 2 disks isn't such a good idea
> for that case, since it just introduces seeks rather than keep up with
> the streaming speed.
> Balancing seeks; there might be some theoretical advantage because you
> could, again in theory, do shorter seeks if you keep one head at the
> inside and one the other disk head on the outside. In practice... a lot
> of the seek time is rotational latency so it's not as big a deal as it
> may sound; the moment you seek you pay a ton.

Ok, I see.  This makes sense.  It is a single thread.  I did kindof
expect that since the spatial locality of the metadata and files
themselves (thousands of 2K byte files being read in a different order
from which they were created) should not be very good, the kernel
would round-robin (or probably something better) the requests (single
blocks and sequential groups of blocks) between drives.

So, if I were to divide these reads across multiple threads, I would
see requests to both drives?  I'm wondering now if that would really
help, although as far as I can tell, what I'm doing is dominated by
seek time.

And the kernel pays attention to which thread caused a given request?
What if you have two threads alternatively reading one file?  (Which
would obviously have to be serialized by locks.)  Just curious.  :)

> if your application is single threaded this isn't totally unexpected as
> a result...

Oh, and one other question.  I know the drives are AHCI capable, and
when I read the drive flags, they report that it's enabled, and that
the queue depth is 31.  For the controller, the BIOS has three
settings, IDE, AHCI, and RAID.  In IDE mode, NCQ and other AHCI
features are disabled.  Unfortunately, the BIOS and manual for the
motherboard do not state that AHCI features are enabled in RAID mode.
Is there a way I can query to kernel to see if it's actually USING
NCQ?

The reason I'm on about this is that the workloads I'm throwing at
this computer are (sometimes) badly bottlenecked by the disks, so if I
can get better throughput, that would help a lot.

Thank you for your help.

-- 
Timothy Normand Miller
http://www.cse.ohio-state.edu/~millerti
Open Graphics Project
--
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/