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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
