Re: [RFC][PATCH v3] readahead: introduce O_RANDOM for POSIX_FADV_RANDOM

[Quentin Barnes]

On Sun, Jan 03, 2010 at 11:33:28PM -0800, Christoph Hellwig wrote:
> On Mon, Jan 04, 2010 at 04:17:19PM +1100, Stephen Rothwell wrote:
> > > @@ -80,6 +80,10 @@
> > >  #define O_NDELAY	O_NONBLOCK
> > >  #endif
> > >  
> > > +#ifndef O_RANDOM
> > > +#define O_RANDOM	010000000	/* random access pattern hint */
> > > +#endif
> > 
> > This value conflicts with O_CLOEXEC on alpha and parisc and O_NOATIME on
> > sparc.
> 
> Also when I tried to use this value for O_RSYNC and tested it I could
> not actually see it getting propagated by the open code.
> 
> Eitherway I don't think an O_ value is a good idea for a simple access
> pattern hint.

Could you expand on that?

I was surprised by Wu's O_RANDOM approach, but after thinking about
it, I liked it.  I'm used to seeing (on non-UNIX OSes) a parameter
as part of the open syscall that announces to the OS what the app's
access strategy through that file descriptor will be for that file.
An issue with the current fadvise(2) approach is for random access
files it necessitates two syscalls (open plus fadvise) for what
could be or should be only one syscall (open).

My guess on your issue is that open(2) should take only flags that
are necessary for the open state itself and therefore can't be
implemented as a separate and later syscall.  I would generally
agree with that.  There is however already at least two exceptions
to that principle, the O_SYNC and O_DIRECT flags.  They are access
states though.  I guess the question is whether to think of the
O_RANDOM flag as a "hint" or as an "access strategy".

Quentin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/