On 2010-01-04, at 09:50, Quentin Barnes wrote:
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.
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).
Given that syscall overhead is very minimal, especially since fadvise
is only setting some in-memory state and doesn't have to flush cache
or anything, I don't see that as a significant reason to consume an O_
flag. Those flags are essentially limited to 32-bit values, or 32-bit
applications wouldn't be able to use all of the flags, and we are
already into the mid-20's of bits.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
--
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
