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. 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? I'm inclined to stick with the status quo; but could be persuaded by a chorus behind you. Hugh p.s. You said "O_DIRECT (for example)" - what other open flag do you think tmpfs should support which it does not? - 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/