linux-kernel - Re: open(O_DIRECT) on a tmpfs?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <459D290B.1040703@tmr.com>
Date:	Thu, 04 Jan 2007 11:19:23 -0500
From:	Bill Davidsen <davidsen@....com>
To:	Hugh Dickins <hugh@...itas.com>
CC:	Linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: open(O_DIRECT) on a tmpfs?

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