Re: Directory unremovable on ext4 no_journal mode

["Darrick J. Wong" <darrick.wong@oracle.com>]

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