Re: [rfc patch 2/2] direct-io: remove address alignment check

[Tejun Heo <htejun@gmail.com>]

Badari Pulavarty wrote:
> Tejun Heo wrote:
> 
>> 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.
>>
> 
> I can imagine a reason for relaxing the alignment. I keep getting asked
> whether we can do "O_DIRECT mount option".  Database folks wants to
> make sure all the access to files in a given filesystem are O_DIRECT
> (whether they are accessing or some random program like ftp, scp, cp
> are acessing them). This was mainly to ensure that buffered accesses to
> the file doesn't polute the pagecache (while database is using O_DIRECT
> access). Seems like a logical request, but not easy to do :(
> 
> Thanks,
> Badari

  I don't know much about VM, but, if that's necessary, I think that 
limiting pagecache size per mounted fs (or by some other applicable 
category) is easier/more complete approach.  After all, you cannot mmap 
w/ O_DIRECT and many programs (gcc, ld come to mind) mmap large part of 
their memory usage.

  Thanks.

-- 
tejun