Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 10 Jun 2005 10:10:47 +0200
From:      "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To:        Jeff Roberson <jroberson@chesapeake.net>
Cc:        arch@FreeBSD.org, Pawel Jakub Dawidek <pjd@FreeBSD.org>
Subject:   Re: simplify disksort, please review. 
Message-ID:  <17437.1118391047@critter.freebsd.dk>
In-Reply-To: Your message of "Fri, 10 Jun 2005 04:05:52 EDT." <20050610040302.S16943@mail.chesapeake.net> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <20050610040302.S16943@mail.chesapeake.net>, Jeff Roberson writes:
>On Thu, 9 Jun 2005, Poul-Henning Kamp wrote:
>
>> In message <20050609193008.GB837@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@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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17437.1118391047>