Re: How are reads and writes kept in order in raid5.c?

On Thursday February 19, nathapl@cs.okstate.edu wrote:

Yes, I think that clears it up.

So, a single stripe (or even a single chunk) could certainly have both 
outstanding read and write requests, but they are guaranteed to not be 
overlapping.

Is it also safe to assume that you'd never have outstanding, overlapping 
write requests either (since order is not maintained within the bio
list)?

I think the code tries to keep writes in order - at least it used to.
Maybe it doesn't in 2.6
It would also warn if there were two concurrent writes.  This warning
did trigger a couple of times, and it was always due to a bug in the
filesystem.

I always thought the drive/device driver was responsible for keeping 
requests in order.  But you're saying that's been delegated to the 
filesystem, correct?

Device drivers are expected to re-order requests to make best use of
the device, though re-ordering two requests for the same block doesn't
make a lot of sense.

But yes, the filesystem is expected not to do anything silly, and have
two concurrent IO requests for the same block fits in the category of
"silly".

NeilBrown

I am planning on updating a server with the idea of migrating components
someday to a beefier system. At this moment I'm leaning toward Adaptec
SCSI and using mdadm with it. Should I prefer the 29160 which doesn't do
hardware raid or the 29320 which includes raid but which can be disabled
in the bios?

Other than lower cost, anything to be gained by limiting myself to 160
M/s?

Thanks, BobH
-- 
Bob Hillegas [off-list ref]