Re: O_DIRECT fails in some kernel and FS

[Chris Mason <mason@suse.com>]

On Monday, February 04, 2002 10:13:37 AM -0500 Jeff Garzik <jgarzik@mandrakesoft.com> wrote:

> Andi Kleen wrote:
>> 
>> Jeff Garzik <garzik@havoc.gtf.org> writes:
>> 
>> > On Sat, Feb 02, 2002 at 02:16:41PM -0600, Stephen Lord wrote:
>> > > Can't you fall back to buffered I/O for the tail? OK it complicates the
>> > > code, probably a lot, but it keeps things sane from the user's point of
>> > > view.
>> > 
>> > For O_DIRECT, IMHO you should fail not fallback.  You're simply lying
>> > to the underlying program otherwise.
>> 
>> It's just impossible to write a tail which is smaller than a disk block
>> without another buffer.
> 
> I argue, for reiserfs:
> 
> For O_DIRECT writes, the preferred behavior is to write disk blocks
> obtained through the normal methods (get_block, etc.), and fully support
> inodes for which file tails do not exist.

Done ;-)

> 
> For O_DIRECT reads, if the data is determined to be in a file tail,
> ->direct_IO should either (a) fail or (b) dump the file tail to a normal
> disk block before performing ->direct_IO.

The current patch does A.  Another option is to change the reiserfs open
code to detect the tail and do an -EINVAL for o_direct.  This gives the
application a better way to fall back to normal open methods than returning
an error during the read.

Just to restate, the current O_DIRECT code can never hit a reiserfs tail in 
the normal case.  By definition, reiserfs tails are not block aligned, and 
O_DIRECT writes are.  The only time it is a concern is with a screwy 
interaction between expanding truncates and tails on kernels < 2.4.17.  
Since most O_DIRECT users are databases, and tails are never created on
files > 16k in size, I don't expect anyone to ever see the reiserfs 
triggered -EINVAL from the current patch (famous last words).

-chris