Alignment of disk-I/O from userland.

[Greg 'groggy' Lehey]

On Tuesday,  7 October 2003 at  8:29:17 +0200, Poul-Henning Kamp wrote:
> In message <200310061753.28562.sam at errno.com>, Sam Leffler writes:
>> On Monday 06 October 2003 04:11 pm, Poul-Henning Kamp wrote:
>>> In message <20031006163218.L55190 at pooker.samsco.home>, Scott Long writes:
>>	...stuff deleted...
>>>> As for returning an error code for a buffer that we (arbitrarily) believe
>>>> to be too big to align, [...]
>>>
>>> I have never advocated returning an error based on "alignment and size",
>>> only based on alignment alone.
>>
>> Imposing this restriction is a major semantic change that I consider a very
>> bad idea.  You are basically imposing the semantics of O_DIRECT on all i/o
>> operations going to a device.  I think it is important to give best effort to
>> support unaligned operations `by default.  I can imagine restricting this to
>> some upper size bound but existing applications, regardless of how well you
>> consider them to be written, must continue to work.
>
> Now now, you are missing two of the finer points:
>
> 1:  Not "on all i/o operations going to a device", but rather "on i/o
>     operations which take the physread/write fast-path to avoid a copyin/out
>     overhead."  (disks and tapes mostly).

Ah.  That's a whole different story.

>  Ttys, /dev/null and all the "typical" devices are unaffected.

This is what I thought you meant at first, but your example using
stdin suggested differently.

Yes, that's not such a serious restriction.

> 2: Right now we _do_ impose this restriction, but our
> error-reporting is wildly inaccurate.

And this is a pretty good indication that we're not going to break a
lot of things with it.

If this only applies to special devices, I don't see a problem with
it.

Greg
--
See complete headers for address and phone numbers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20031007/da473fbf/attachment.bin