On Tue, Apr 26, 2016 at 09:49:46AM +1000, Dave Chinner wrote: > Why not just transparently fall back to buffered IO if direct IO > cannot be done? Saves people from wondering why applications fail > on one ext4 filesystem and not another.... Some file systems return EINVAL if they don't support O_DIRECT. In fact, _require_odirect in xfstests relies on this fact. The question of whether it's better to silently fall back to buffered I/O and fail to provide the O_DIRECT functionality requested by the user, or whether it's better to fail with EINVAL is an interesting one. It is possible for applications (or xfstests tests) that expect O_DIRECT functionality but don't get it can end up fail, sometimes in subtle ways that might be tricky to debug. It would be nice if there was some way to answer the question, "does O_DIRECT work or is it a placebo", perhaps via an extension to statfs(2), but we don't have that today. I ran into this because I was investigating an xfstests failure, and it was because we were claiming to support O_DIRECT when in fact we weren't, and this was causing a test failure. OTOH, after I applied this patch, there were a handful of tests that are using O_DIRECT without using the _require_odirect assertion, and we were passing those tests essentially by luck. So depending how we decide to deal with this case, I can send patches that add the missing _require_odirect to those tests, and/or send tests that add more ext4-specific checks to _require_odirect (e.g., don't try to use O_DIRECT in data=journal, or if inline_data is enabled, or if encryption is enabled). What do folks think? - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
