[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180410003837.GA7493@magnolia>
Date: Mon, 9 Apr 2018 17:38:37 -0700
From: "Darrick J. Wong" <darrick.wong@...cle.com>
To: Jayashree Mohan <jayashree2912@...il.com>
Cc: linux-ext4@...r.kernel.org, fstests <fstests@...r.kernel.org>,
Vijaychidambaram Velayudhan Pillai <vijay@...utexas.edu>
Subject: Re: Directory unremovable on ext4 no_journal mode
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
Powered by blists - more mailing lists