xfs
[Top] [All Lists]

Re: 2.4.19pre5aa1 and splitted vm-33

To: Andrea Arcangeli <andrea@xxxxxxx>
Subject: Re: 2.4.19pre5aa1 and splitted vm-33
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Sun, 31 Mar 2002 20:00:38 +0100
Cc: linux-kernel@xxxxxxxxxxxxxxx, linux-xfs@xxxxxxxxxxx
In-reply-to: <20020331203830.D1331@xxxxxxxxxxxxxxxxx>; from andrea@xxxxxxx on Sun, Mar 31, 2002 at 08:38:30PM +0200
Mail-followup-to: Christoph Hellwig <hch@xxxxxxxxxxxxx>, Andrea Arcangeli <andrea@xxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, linux-xfs@xxxxxxxxxxx
References: <20020331164815.A1331@xxxxxxxxxxxxxxxxx> <20020331191059.A16769@xxxxxxxxxxxxxxxxxxxxx> <20020331203830.D1331@xxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mutt/1.2.5.1i
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.


<Prev in Thread] Current Thread [Next in Thread>