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

[Tejun Heo <htejun@gmail.com>]

Badari Pulavarty wrote:
> On Fri, 2005-07-15 at 17:23 +0900, Tejun Heo wrote:
> 
>>Badari Pulavarty wrote:
> 
> ...
> 
>>>> 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.
> 
> 
> I agree. I guess for mmap()ed access we can kick it back to buffered
> mode.
> 
> I don't think limiting pagecache use per filesystem is an acceptable
> option. In fact, database folks exactly want this -  to limit the
> pagecache use by filesystems - but I don't think its right thing to do,
> so I am trying to propose mount O_DIRECT as an alternative (if its
> feasible).

  Just out of curiosity, can you tell me why you think limiting 
pagecache isn't the right thing to do (tm)?  O_DIRECT mount seems to me 
incomplete/complex solution (DMA alignment etc...).  Forgive me if this 
issue has been discussed to death already.

-- 
tejun