On Mon, Apr 09, 2018 at 07:08:13PM -0500, Jayashree Mohan wrote: > 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 You're supposed to run e2fsck after a crash to clean up the metadata. nojournal disables the piece that takes care of that. --D > 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
