O_DIRECT, ext3fs, kernel 2.4.32... again

[DervishD <lkml@dervishd.net>]

    Hi all :)

    I don't know if the patch to backport O_DIRECT support for ext3
under kernel 2.4.3x was finally accepted or not, but I'm having what
I consider inconsistent behaviour due to O_DIRECT under ext3fs and
kernel 2.4.32.

    I can understand that ext3 doesn't support O_DIRECT, and that's
not a problem for me. In fact, if an app really needs O_DIRECT and
the underlying filesystem doesn't support it, the app should fail, no
more and no less.

    The problem I'm having is with dvd+rw-tools. Apart from all the
problems regarding DVD writing, I have another problem: the open64
call with the O_DIRECT flag succeeds, but any subsequent read
operation fails. IMHO, if the filesystem is going to return EINVAL
for any read/write operation over an O_DIRECT'ed filehandle, it
should return an error when opening, too.

    The growisofs program tries to open a file using O_DIRECT and the
call succeeds, so it tries to read from that filehandle and the
result is always EINVAL. I've tried a test program, just in case the
problem was memory alignment of the buffer, but nothing is solved (I
used posix_memalign and some recipe I found in this list, using the
st_blksize and the st_size of the file). The problem seems to be in
the O_DIRECT flag, because removing it from the open call makes all
work.

    Shouldn't ext3fs return an error when the O_DIRECT flag is used
in the open call? Is the open call userspace only and thus only libc
can return such error? Am I misunderstanding the entire issue and
this is a perfectly legal behaviour (allowing the open, failing in
the read operation)?

    Thanks a lot in advance :)))

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to... RAmen!