Hugh Dickins wrote:
On Thu, 4 Jan 2007, Michael Tokarev wrote:
I wonder why open() with O_DIRECT (for example) bit set is
disallowed on a tmpfs (again, for example) filesystem,
returning EINVAL.
Because it would be (a very small amount of) work and bloat to
support O_DIRECT on tmpfs; because that work didn't seem useful;
and because the nature of tmpfs (completely in page cache) is at
odds with the nature of O_DIRECT (completely avoiding page cache),
so it would seem misleading to support it.
You have a valid view, that we should not forbid what can easily be
allowed; and a valid (experimental) use for O_DIRECT on tmpfs; and
a valid alternative perception, that the nature of tmpfs is already
direct, so O_DIRECT should be allowed as a no-op upon it.
It does seem odd to require that every application using O_DIRECT would
have to contain code to make it work with tmpfs, or that the admin would
have to jump through a hoop and introduce (slight) overhead to bypass
the problem, when the implementation is mostly to stop disallowing
something which would currently work if allowed.
On the other hand, I'm glad that you've found a good workaround,
using loop, and suspect that it's appropriate that you should have
to use such a workaround: if the app cares so much that it insists
on O_DIRECT succeeding (for the ordering and persistence of its
metadata), would it be right for tmpfs to deceive it?
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'm inclined to stick with the status quo;
but could be persuaded by a chorus behind you.
This isn't impacting me directly, but I can imagine some applications I
have written, which currently use O_DIRECT, failing if someone chose the
put a control file on tmpfs. I may be missing some benefit from
restricting O_DIRECT, feel free to point it out.
Hugh
p.s. You said "O_DIRECT (for example)" - what other open
flag do you think tmpfs should support which it does not?
--
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]
