Hi, We stumbled upon what seems to be a bug that makes a “directory unremovable”, on ext4 when mounted with no_journal option. A sequence of operations described below led to the following state : “A directory that was renamed, was persisted in both parent and target directories, with the same inode number. This also means the rename was non-atomic on storage. In addition, the renamed directory becomes unremovable on the target with FS-error logged in dmesg.” Here are more details of the workload and the corresponding failure. Workload : mkdir /mnt/test/X and /mnt/test/Y mkdir X/Z sync() rename X/Z Y/Z fsync Y —-Crash now—- Remount ls X and Y (You will see Z is present in both directories X and Y, and has same inode) rmdir test_dir/X/Z (This succeeds) rmdir test_dir/Y/Z (This fails with a FS error logged in dmesg) Results: rmdir: failed to remove '/mnt/test/Y/Z': Structure needs cleaning The corresponding dmesg log has the following error message : [66799.504124] EXT4-fs error (device cow_ram_snapshot1_0): ext4_lookup:1576: inode #12: comm rmdir: deleted inode referenced: 14 [66799.504131] EXT4-fs (cow_ram_snapshot1_0): Remounting filesystem read-only The sequence of operations listed above is making dir Z unremovable from dir Y, which seems like unexpected behavior. Could you provide more details on the reason for such behavior? We understand we run this on no_journal mode of ext4, but would like you to verify if this behavior is acceptable. Do let us know if we are missing any detail here. Thanks, Jayashree Mohan
