Re: open(O_DIRECT) on a tmpfs?

[Bill Davidsen <davidsen@tmr.com>]

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 <davidsen@tmr.com>
  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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/