From: Tejun Heo <htejun@gmail.com>
To: Daniel McNeil <daniel@osdl.org>
Cc: "linux-aio@kvack.org" <linux-aio@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [rfc patch 2/2] direct-io: remove address alignment check
Date: Fri, 15 Jul 2005 09:28:08 +0900 [thread overview]
Message-ID: <42D70318.1000304@gmail.com> (raw)
In-Reply-To: <1121298112.6025.21.camel@ibm-c.pdx.osdl.net>
Daniel McNeil wrote:
> This patch relaxes the direct i/o alignment check so that user addresses
> do not have to be a multiple of the device block size.
>
> I've done some preliminary testing and it mostly works on an ext3
> file system on a ide disk. I have seen trouble when the user address
> is on an odd byte boundary. Sometimes the data is read back incorrectly
> on read and sometimes I get these kernel error messages:
> hda: dma_timer_expiry: dma status == 0x60
> hda: DMA timeout retry
> hda: timeout waiting for DMA
> hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> ide: failed opcode was: unknown
> hda: drive not ready for command
>
> Doing direct-io with user addresses on even, non-512 boundaries appears
> to be working correctly.
>
> Any additional testing and/or comments welcome.
>
Hi, Daniel.
I don't think the change is a good idea. We may be able to relax
alignment contraints on some hardware to certain levels, but IMHO it
will be very difficult to verify. All internal block IO code follows
strict block boundary alignment. And as raw IOs (especially unaligned
ones) aren't very common operations, they won't get tested much. Then
when some rare (probably not an open source one) application uses it on
some rare buggy hardware, it may cause *very* strange things.
Also, I don't think it will improve application programmer's
convenience. As each hardware employs different DMA alignemnt, we need
to implement a way to export the alignment to user space and enforce it.
So, in the end, user application must do aligned allocation
accordingly. Just following block boundary will be easier.
I don't know why you wanna relax the alignment requirement, but
wouldn't it be easier to just write/use block-aligned allocator for such
buffers? It will even make the program more portable.
--
tejun
next prev parent reply other threads:[~2005-07-15 0:28 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-13 23:43 [rfc patch 2/2] direct-io: remove address alignment check Daniel McNeil
2005-07-14 23:16 ` Badari Pulavarty
2005-07-14 23:44 ` Daniel McNeil
2005-07-15 5:27 ` Badari Pulavarty
2005-07-15 20:06 ` Daniel McNeil
2005-07-15 0:28 ` Tejun Heo [this message]
2005-07-15 5:18 ` Badari Pulavarty
2005-07-15 8:23 ` Tejun Heo
2005-07-15 17:54 ` Badari Pulavarty
2005-07-16 3:50 ` Tejun Heo
2005-07-15 16:56 ` Joel Becker
2005-07-15 17:50 ` Badari Pulavarty
2005-07-15 19:16 ` Joel Becker
[not found] <1121298112.6025.21.camel@ibm-c.pdx.osdl.net.suse.lists.linux.kernel>
2005-07-14 13:18 ` Andi Kleen
2005-07-14 16:02 ` Daniel McNeil
2005-07-14 18:23 ` Andi Kleen
2005-07-14 20:40 ` Daniel McNeil
2005-07-14 23:39 ` Andrew Morton
2005-07-15 0:03 ` Daniel McNeil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42D70318.1000304@gmail.com \
--to=htejun@gmail.com \
--cc=daniel@osdl.org \
--cc=linux-aio@kvack.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox