From: Bill Davidsen <davidsen@tmr.com>
To: Hugh Dickins <hugh@veritas.com>
Cc: Linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: open(O_DIRECT) on a tmpfs?
Date: Thu, 04 Jan 2007 11:19:23 -0500 [thread overview]
Message-ID: <459D290B.1040703@tmr.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0701041242530.27899@blonde.wat.veritas.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
next prev parent reply other threads:[~2007-01-04 16:19 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-04 11:52 open(O_DIRECT) on a tmpfs? Michael Tokarev
2007-01-04 13:08 ` Hugh Dickins
2007-01-04 16:19 ` Bill Davidsen [this message]
2007-01-04 17:09 ` Hugh Dickins
2007-01-04 17:54 ` Peter Staubach
2007-01-04 18:11 ` Bill Davidsen
2007-01-04 18:41 ` Hua Zhong
2007-01-04 19:14 ` Hugh Dickins
2007-01-04 19:35 ` Mark Lord
2007-01-05 6:57 ` Chen, Kenneth W
2007-01-05 14:38 ` Helge Hafting
2007-01-05 14:58 ` Jesper Juhl
2007-01-05 14:59 ` Jesper Juhl
2007-01-04 22:17 ` Denis Vlasenko
2007-01-05 5:30 ` Nick Piggin
2007-01-05 16:20 ` Bill Davidsen
2007-01-06 0:30 ` Denis Vlasenko
2007-01-08 19:42 ` Bill Davidsen
2007-01-05 11:49 ` Michael Tokarev
[not found] <7zzqw-SS-27@gated-at.bofh.it>
2007-01-04 14:47 ` Bodo Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=459D290B.1040703@tmr.com \
--to=davidsen@tmr.com \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.