On Tue, Sep 13, 2016 at 11:53:11AM +1000, Nicholas Piggin wrote: > On Tue, 13 Sep 2016 07:34:36 +1000 > Dave Chinner <david@xxxxxxxxxxxxx> wrote: > But let me understand your example in the absence of that. > > - Application mmaps a file, faults in block 0 > - FS allocates block, creates mappings, syncs metadata, sets "no fsync" > flag for that block, and completes the fault. > - Application writes some data to block 0, completes userspace flushes > > * At this point, a crash must return with above data (or newer). > > - Application starts writing more stuff into block 0 > - Concurrently, fault in block 1 > - FS starts to allocate, splits trees including mappings to block 0 > > * Crash > > Is that right? No. - app write faults block 0, fs allocates < time passes while app does stuff to block 0 mapping > - fs syncs journal, block 0 metadata now persistent < time passes while app does stuff to block 0 mapping > - app structure grows, faults block 1, fs allocates - app adds pointers to data in block 1 from block 0, does userspace pmem data sync. *crash* > How does your filesystem lose data before the sync > point? After recovery, file has a data in block 0, but no block 1 because the allocation transaction for block 1 was not flushed to the journal. Data in block 0 points to data in block 1, but block 1 does not exist. IOWs, the application has corrupt data because it never issued a data synchronisation request to the filesystem.... ---- Ok, looking back over your example, you seem to be suggesting a new page fault behaviour is required from filesystems that has not been described or explained, and that behaviour is triggered (persistently) somehow from userspace. You've also suggested filesystems store a persistent per-block "no fsync" flag in their extent map as part of the implementation. Right? Reading between the lines, I'm guessing that the "no fsync" flag has very specific update semantics, constraints and requirements. Can you outline how you expect this flag to be set and updated, how it's used consistently between different applications (e.g. cp of a file vs the app using the file), behavioural constraints it implies for page faults vs non-mmap access to the data in the block, how you'd expect filesystems to deal with things like a hole punch landing in the middle of an extent marked with "no fsync", etc? [snip] > If there is any huge complexity or unsolved problem, it is in XFS. > Conceptual problem is simple. Play nice and be constructive, please? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
