linux-kernel - Re: Directory is not persisted after writing to the file within directory if system crashes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAL3q7H5ewZROWz0384L_pLvqWrjNK8mX=-kQb26ZDmpAbBUQ4A@mail.gmail.com>
Date: Sun, 26 Oct 2025 09:04:13 +0000
From: Filipe Manana <fdmanana@...nel.org>
To: Vyacheslav Kovalevsky <slava.kovalevskiy.2014@...il.com>
Cc: clm@...com, dsterba@...e.com, linux-btrfs@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: Directory is not persisted after writing to the file within
 directory if system crashes

On Sat, Oct 25, 2025 at 10:49 AM Vyacheslav Kovalevsky
<slava.kovalevskiy.2014@...il.com> wrote:
>
> On 24/10/2025 19:17, Filipe Manana wrote:
> > I converted that to a test case for fstests and couldn't reproduce,
> > "dir", "file1" and "dir/file2" exist after the power failure.
> >
> > The conversion for fstests:
> >
> > #! /bin/bash
> > # SPDX-License-Identifier: GPL-2.0
> > # Copyright (c) 2025 SUSE S.A.  All Rights Reserved.
> > #
> > # FS QA Test 780
> > #
> > # what am I here for?
> > #
> > . ./common/preamble
> > _begin_fstest auto quick log
> >
> > _cleanup()
> > {
> > _cleanup_flakey
> > cd /
> > rm -r -f $tmp.*
> > }
> >
> > . ./common/filter
> > . ./common/dmflakey
> >
> > _require_scratch
> > _require_dm_target flakey
> >
> > rm -f $seqres.full
> > On 24/10/2025 19:17, Filipe Manana wrote:
> > _scratch_mkfs >>$seqres.full 2>&1 || _fail "mkfs failed"
> > _require_metadata_journaling $SCRATCH_DEV
> > _init_flakey
> > _mount_flakey
> >
> > touch $SCRATCH_MNT/file1
> >
> > _scratch_sync
> >
> > mkdir $SCRATCH_MNT/dir
> > echo -n "hello world" > $SCRATCH_MNT/file1
> > ln $SCRATCH_MNT/file1 $SCRATCH_MNT/dir/file2
> >
> > $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/
> >
> > # Simulate a power failure and then mount again the filesystem to replay the
> > # journal/log.
> > _flakey_drop_and_remount
> >
> > ls -R $SCRATCH_MNT/ | _filter_scratch
> >
> > _unmount_flakey
> >
> > # success, all done
> > _exit 0
>
> I think the line with `echo` may not be the correct translation:
>  > echo -n "hello world" > $SCRATCH_MNT/file1

An echo is just a write...

>
> In the original test, the file was opened with `O_SYNC` flag, if you
> remove it, the directory will be there when the system crashes. I also
> forgot to close the file after the `creat` call in the original test,
> may be important as well.

An O_SYNC, which is what I missed before, is essentially just an
implicit fsync after every write on a file.
Adding an fsync after the echo:

$XFS_IO_PROG -c "fsync" $SCRATCH_MNT/file1

Triggers the problem of "dir" not being persisted.

>
> The test itself is quite weird (why would `dir` be gone after seemingly
> unrelated operation?), any detail can matter.

"dir" should be persisted as well as "dir/file2", according to the
SOMC (Strictly Ordered Metadata Consistency) that Dave Chinner
discussed many times in the past in fstests and btrfs mailing lists.

You should also reach the xfs mailing list and mention that
"dir/file2" is not persisted.

>
> Please run the original test with a real system crash. I will also
> double check everything on my side.

I've said before in another thread: we don't need to trigger qemu
crashes in order to test fsync.
Just use the dm flakey target with fstests - no need to do reboots,
much more practical and way less time consuming.
In 12 years of fixing fsync stuff on btrfs, I haven't yet seen any
case where dm flakey didn't do the job of reproducing issues.

>