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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 11 Nov 2021 15:10:10 +0800
From:   尹欣 <>
Subject: [Question] ext4: different behavior of fsync when use fast commit


Recently, I‘m doing some testing with fast commit feature , and found
there is a slight difference on fsync compared with the normal
journaling scheme.

Here is the example:

-mkdir test/

-create&write test/a.txt

-fsync test/a.txt

-crash (before a full commit)

If fast commit is used then “a.txt” will lost. While the normal
journaling can recover it.

Refer to the description of fsync [1],  fsync will not guarantee the
parent directory to be persisted. So I think it is not an issue.

But fast commit did change the behavior of fsync in ext4,  is this as expected ?

For the root cause of this difference, I found that fast commit will
not add a EXT4_FC_TAG_CREAT tag for directory creation.

In func ext4_fc_commit_dentry_updates(), only directories in s_fc_q
list can be added with EXT4_FC_TAG_CREAT,but seams the newly created
directory inode has no change to be added to s_fc_q.

Shall we just change the “enqueue” param of ext4_fc_track_template()
to 1 , which in __ext4_fc_track_create()?  And make fast commit record
all the inode creation, and do the same things as normal journaling.



Xin Yin

Powered by blists - more mailing lists