linux-kernel - Questions about RAID and I/O scheduler

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-next>] [day] [month] [year] [list]

Message-ID: <m2v100eff551003311324tdc2e567atd2a48e35520e8601@mail.gmail.com>
Date:	Wed, 31 Mar 2010 16:24:09 -0400
From:	Yuehai Xu <yuehaixu@...il.com>
To:	linux-raid@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org, yhxu@...ne.edu, czoccolo@...il.com,
	neilb@...e.de, jens.axboe@...cle.com
Subject: Questions about RAID and I/O scheduler

Hi,

I noticed that some one said NOOP is usually the default I/O scheduler
for hardware RAID. Why not CFQ? Suppose there are just several
sequential read processes, as I know CFQ will keep all the disk heads
of hard raid to serve a process for a while(a time slice), in that
case, CFQ should be the best of all I/O schedulers. Am I right?
Generally, hard raid should have its own I/O scheduler in their
firmware, in that case, the I/O scheduler of OS should do nothing
except dispatch the requests as soon as possible, it is the hard raid
itself to decide how to schedule these requests. From this point of
view, NOOP should be the default one. I am really confused here.

The next question is about the maximal number of disks in disk array,
the fault tolerance should be one limitation because the more the
number of disks, the higher chance of failure. However, may throughput
also be one limitation? Do you know anyone use disk array which
contains large number of disks to handle small requests? Such as 256
disks to handle 4K requests?

Thanks!

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