On Thu, Apr 26, 2018 at 07:59:23PM -0500, Jayashree Mohan wrote: > Thanks for the response. We are using a tool we developed called > CrashMonkey[1] to run crash consistency tests and generate the bug > reports above. We'd be happy to guide you through setting up > CrashMonkey and getting these bugs reproduced. However, if you want to > be able to reproduce them with your current setup (xfstest + > dm-flakey), I have the workload scripts attached to the end of the > mail which might make your task simpler. > > Interestingly we seem to have found another bug that breaks rename > atomicity and results in a previously fsynced file missing. > > Workload: > 1. mkdir A > 2. creat A/bar (*) > 3. fsync A/bar > 4. mkdir B > 5. creat B/bar > 6. rename B/bar A/bar > 7. creat A/foo > 8. fsync A/foo > 9. fsync A > --- crash--- > > When we recover from the crash, we see that file A/bar goes missing. > If the rename did not persist, we expect to see A/bar(*) created in > step 2 above, or if the rename indeed persisted, we still expect file > A/bar to be present. I'm no fsync expert and the lack of standard or well defined behaviour (mentioned elsewhere) leads me to question, on what do you base your expectations? Not only for this report, but in general during your testing. Comparing various filesystems will show that at best it's implementation defined and everybody has their own reasons for doing it one way or another, or request fsync at particular time etc. We have a manual page in section 5 that contains general topics of btrfs, so documenting the fsync specifics would be good. -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
