simplify disksort, please review.
phk at phk.freebsd.dk
Fri Jun 10 08:11:01 GMT 2005
In message <20050610040302.S16943 at mail.chesapeake.net>, Jeff Roberson writes:
>On Thu, 9 Jun 2005, Poul-Henning Kamp wrote:
>> In message <20050609193008.GB837 at darkness.comp.waw.pl>, Pawel Jakub Dawidek writes:
>> >The one example of how the order can be broken (write(offset, size)):
>> > write(1024, 512)
>> > write(0, 2048)
>> If you issue these two requests just like that, you get no guarantee
>> which order they get written in.
>> It's not just disksort which might surprise you, tagged queuing and
>> write caches may mess up your day as well.
>Anyway, it's really not important to solve at the disk queue layer,
>because it's only an issue with raw devices, and it's very irregular to
>have multiple processes opening the same raw device to issue a lot of io
>of different sizes.
It will not be solved at any level, because it would require the GEOM
layer to either make all writes strictly synchronous, a total no-go,
or keep very expensive housekeeping of which requests are outstanding
so we can block conflicting writes etc.
This is something that belongs 100% in the code issuing the I/O requests
and if some of that code does something stupid, it looses and that is
how it should be.
Jeff is correct that the buffer-cache mostly will prevent people from
shooting their feet off, but nothing prevents a GEOM class from making
a fool of itself.
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
More information about the freebsd-arch