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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/