Peter Staubach wrote:
Hugh Dickins wrote:
On Thu, 4 Jan 2007, Bill Davidsen wrote:
In many cases the use of O_DIRECT is purely to avoid impact on cache
used by
other applications. An application which writes a large quantity of
data will
have less impact on other applications by using O_DIRECT, assuming
that the
data will not be read from cache due to application pattern or the
data being
much larger than physical memory.
I see that as a good argument _not_ to allow O_DIRECT on tmpfs,
which inevitably impacts cache, even if O_DIRECT were requested.
But I'd also expect any app requesting O_DIRECT in that way, as a caring
citizen, to fall back to going without O_DIRECT when it's not supported.
I suppose that one could also argue that the backing store for tmpfs
is the memory itself and thus, O_DIRECT could or should be supported.
I suspect that many applications don't try to distinguish an open error
beyond pass/fail. If the application actually tried to correct errors,
like creating missing directories, it might, but if the error is going
to be reported to the user and treated as fatal there's probably no
logic to tell "can't do it" from "could if you asked the right way."
I always thought the difference between Linux and Windows was the "big
brother" attitude. If someone wants to use O_DIRECT and tmpfs, and the
system can allow it, why have code to block it because someone thinks
they know better how the users should do things.
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
