[1494] in linux-scsi channel archive
Re: elevator sorting for the scsi subsystem.
daemon@ATHENA.MIT.EDU (Gerard Roudier)
Sun Mar 2 17:32:29 1997
Date: Sun, 2 Mar 1997 23:28:39 +0000 (GMT)
From: Gerard Roudier <groudier@club-internet.fr>
To: Dario_Ballabio@milano.europe.dg.com
cc: linux-scsi@vger.rutgers.edu, lnz@dandelion.com
In-Reply-To: <199703022017.VAA21095@milano.europe.dg.com>
On Sun, 2 Mar 1997 Dario_Ballabio@milano.europe.dg.com wrote:
> If a request writes sectors 2 and 3, filling with 1's the two blocks
> and then another request writes sectorr 1 and 2 filling with 0's,
> at the end sector 2 shoud be filled with 0's. If we sort the two
> requests or if the drive reorder them, at the end sector 2 is
> filled with 1's, which is not the expected result.
> I cheched that there are (rare) cases of overlapping write requests
> in normal operations, tipically at the very beginning of the
> disk partition. My concern is that if we use simple queue tags
> for write requests, cases as the above are likely to happen soon
> or later, causing randomic disk corruptions.
> I belive that we can safely sort write requests only provided that
> there are no overlapping requests in the batch to be sorted.
> In any case I would always use ordered queue tags for write requests.
>
If you observed in Linux overlapped commands with a write operation
among them, my opinion is that you've found a bug.
I expect the kernel to garantee this never to happen.
So, my opinion is that using ordered tag for write request is just
paranoia.
On the other hand, each time you send such a tag you have every chance
to break pending optimizations in the disk firmware.
My guess is that even if you only do 1 ordered write for 10 read that may
have very bad effects on performances. So, my opinion is that it is
silly too. (Dont expect simple benchmarks as bonnie or iozone to see
such bad things).
Now, you can imagine a system that allows asynchronous IO for application
and/or raw IO or you can imagine some part of the kernel doing asynchronous
IO. You can imagine too that this stuff does concurrent IO requests on a
given block and expects the IO subsystem to not reorder IOs ...
Even in such cases, using a value 0 (restricted reordering) for queue
algorithm modifier in the control mode page will allow to debug such stuff
the same way you would use ordered queue tag for write operations, since
it guarantees same final value of all data observable to be the same as it
would be executed without tags.
I use SIMPLE QUEUE TAG for all operations and QAM=1 (unrestricted
reordering) on all my hard disks and I never have had any problems
under Linux.
Gerard.
