On Fri, Apr 1, 2011 at 8:19 AM, Ted Ts'o <tytso@xxxxxxx> wrote: > On Wed, Mar 30, 2011 at 07:28:34AM -0400, Ric Wheeler wrote: >> >> What possible semantics could you have? >> >> If you ever write concurrently from multiple processes without >> locking, you clearly are at the mercy of the scheduler and the >> underlying storage which could fragment a single write into multiple >> IO's sent to the backend device. >> >> I would agree with Dave, let's not make it overly complicated or try >> to give people "atomic" unbounded size writes just because they set >> the O_DIRECT flag :) > > I just want to have it written down. After getting burned with ext3's > semantics promising more than what the standard guaranteed, I've just > gotten paranoid about application programmers getting upset when > things change on them --- and in the case of direct I/O, this stuff > isn't even clearly documented anywhere official. > > I just think it's best that we document it the fact that concurrent > DIO's to the same region may result in completely arbitrary behaviour, > make sure it's well publicized to likely users (and I'm more worried > about the open source code bases than Oracle DB), and then call it a day. > > The closest place that we have to any official documentation about > O_DIRECT semantics is the open(2) man page in the Linux manpages, and > it doesn't say anything about this. It does give a recommendation > against not mixing buffered and O_DIRECT accesses to the same file, > but it does promise that things will work in that case. (Even if it > does, do we really want to make the promise that it will always work?) when writing DIO to indirect mapped file holes, we fall back to buffered write (so we won't expose stale data in the case of a crash) concurrent DIO reads to that file (before data writeback) can expose stale data. right? do you consider this case mixing buffered and DIO access? do you consider that as a problem? the case interests me because I am afraid we may have to use the fallback trick for extent move on write from DIO (we did so in current implementation anyway). of course, if we end up implementing in-memory extent tree, we will probably be able to cope with DIO MOW without fallback to buffered IO. > > In any case, adding some text in that paragraph, or just after that > paragraph, to the effect that two concurrent DIO accesses to the same > file block, even by two different processes will result in undefined > behavior would be a good start. > > - Ted > _______________________________________________ > Lsf mailing list > Lsf@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linux-foundation.org/mailman/listinfo/lsf > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
