On Mon, Dec 27, 2010 at 2:23 AM, Olaf van der Spek <olafvdspek@xxxxxxxxx> wrote: > On Sun, Dec 26, 2010 at 10:59 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >> Whether or not the new data is durable is entirely up to the >> programmer to decide. > > Right > >> Perhaps all that is missing is an fdatawait(fd) API or fdatawait_async(fd) API, >> which should be very simple to implement (right?). >> >> So an editor that doesn't want to be too pushy, will just save a temp file, >> wait for it to sync on the system's free time and then swap the data with >> the original file in an atomic manner, which preserves metadata. >> >> If the system takes too long to sync, the editor can always issue >> fdatasync(fd) when it is tired of waiting. >> >> Will that make you happy, Olaf? >> If you are not happy from the new copy not being available to all >> system users until >> fdatasync is done, then we will call it "atomic, isolated non-durable >> file write API", OK? > > No. Take the compiler case. Ideally you'd like file data updates to be > atomic, but waiting until an update hits disk before it's visible to > other processes is unacceptable. How about sending output to an intermediate name, then before it is used in the next stage of the processor output, fsync+rename to the expected name? make clean would delete any intermediate names. -- 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
