Hi, We found two more cases where the btrfs behavior is a little strange. In one case, an fsync-ed file goes missing after a crash. In the other, a renamed file shows up in both directories after a crash.
Workload 1: mkdir A mkdir B mkdir A/C creat B/foo fsync B/foo link B/foo A/C/foo fsync A -- crash -- Expected state after recovery: B B/foo A A/C exist What we find: Only B B/foo exist A is lost even after explicit fsync to A. Workload 2: mkdir A mkdir A/C rename A/C B touch B/bar fsync B/bar rename B/bar A/bar rename A B (replacing B with A at this point) fsync B/bar -- crash -- Expected contents after recovery: A/bar What we find after recovery: A/bar B/bar We think this breaks rename's atomicity guarantee. bar should be present in either A or B, but now it is present in both. Thanks, Vijay -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
