Re: 2.4.19pre5aa1 and splitted vm-33

[Christoph Hellwig]

On Sun, Mar 31, 2002 at 08:38:30PM +0200, Andrea Arcangeli wrote:
> Hmm that's a problem. BTW, is there any valid reason xfs isn't
> implementing O_DIRECT via the direct_IO address space operation like the
> other filesystems ext2/reiserfs/nfs? (of course I'm talking long term, I
> don't pretend to change that in one day, for the short term we should
> still allow xfs to use its own internal methods of doing O_DIRECT)

For definitve answers you have to ask Steve or some else from the XFS crow,
but if you look at the XFS data I/O path is is completly different from
the generic Linux filesystems due to the IRIX history/compatiblity and the
'need' for features not present in the core kernel.  Before 2.4.10 one
of those was O_DIRECT, btw..

> Fixing that should be a one liner setting a_ops->direct_IO to
> ERR_PTR(-1L) within xfs. Comments?

Looks good to me.

> 
> > For the open case putting the check into generic_file_open sounds good to me,
> 
> One problem with generic_file_open is that we'd need to rely on all
> lowlevel open callbacks to do the check properly if they don't support
> O_DIRECT and we'd need to duplicate code, only a few fs uses
> generic_file_open.  Lefting it in the vfs looked cleaner, it reduces the
> check to a few liner patch.
> 
> The lowlevel callback can always drop the kiovec during its own ->open
> if they don't need it, even if they uses direct_IO, like nfs.

I don't think this is a good design decision, but I can live with it for
2.4 - for 2.5 I'm still hoping for bcrls kvec to replace the current kiobuf
stuff and we have to see what that means for O_DIRECT.

> > kiobufs even if XFS doesn't need them..
> 
> Chuck's patch is handling fcntl as well, do you see any problem there?
> (modulo the fact the kiovec is pre-allocated even if not necessary, like
> in open(2)?)

It's this same issue, there is no other problem in my eyes.