![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2007-01-04 17:23 [from the cache] ©2003-2008 | |||||||||||||