* [PATCH RESEND] ext4:fix different behavior of fsync when use fast commit @ 2021-12-24 6:57 Xin Yin 2022-01-06 3:22 ` Theodore Ts'o 0 siblings, 1 reply; 3+ messages in thread From: Xin Yin @ 2021-12-24 6:57 UTC (permalink / raw) To: harshadshirwadkar, tytso, adilger.kernel Cc: linux-ext4, linux-kernel, Xin Yin For the follow test 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. We should keep behavior of fsync unchanged when use fast commit. other report: https://www.spinics.net/lists/linux-ext4/msg80514.html Signed-off-by: Xin Yin <yinxin.x@bytedance.com> --- fs/ext4/fast_commit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c index 3deb97b22ca4..4b843648ffe5 100644 --- a/fs/ext4/fast_commit.c +++ b/fs/ext4/fast_commit.c @@ -423,7 +423,7 @@ void __ext4_fc_track_create(handle_t *handle, struct inode *inode, args.op = EXT4_FC_TAG_CREAT; ret = ext4_fc_track_template(handle, inode, __track_dentry_update, - (void *)&args, 0); + (void *)&args, 1); trace_ext4_fc_track_create(inode, dentry, ret); } -- 2.20.1 ^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH RESEND] ext4:fix different behavior of fsync when use fast commit 2021-12-24 6:57 [PATCH RESEND] ext4:fix different behavior of fsync when use fast commit Xin Yin @ 2022-01-06 3:22 ` Theodore Ts'o 2022-01-07 8:49 ` [External] " Xin Yin 0 siblings, 1 reply; 3+ messages in thread From: Theodore Ts'o @ 2022-01-06 3:22 UTC (permalink / raw) To: Xin Yin; +Cc: harshadshirwadkar, adilger.kernel, linux-ext4, linux-kernel On Fri, Dec 24, 2021 at 02:57:28PM +0800, Xin Yin wrote: > For the follow test 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. The problem is that your proposed fix: > diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c > index 3deb97b22ca4..4b843648ffe5 100644 > --- a/fs/ext4/fast_commit.c > +++ b/fs/ext4/fast_commit.c > @@ -423,7 +423,7 @@ void __ext4_fc_track_create(handle_t *handle, struct inode *inode, > args.op = EXT4_FC_TAG_CREAT; > > ret = ext4_fc_track_template(handle, inode, __track_dentry_update, > - (void *)&args, 0); > + (void *)&args, 1); > trace_ext4_fc_track_create(inode, dentry, ret); > } affects both file creations as well as directory creations (mkdir). Putting the inode on the fast commit list is something that is meant for files, and means that on a fast commit we need to force the data blocks out. So it seems that isn't the right fix for the problem. Why do something really simple? Look at the parent directory's inode, and check its i_sync_tid. If it's not equal to handle->h_transaction->t_tid, then it's safe to do the fast commit. If it's equal to the current transaction, we can either force a full commit. Optionally, in the case where i_sync_tid == current tid, since there's a chance that the parent directory's inode could have been freshly fetched from disk (see __ext4_iget() in fs/ext4/inode.c), we could compare its i_crtime against ktime_get_real_seconds(), and if the inode was created in the last 2*journal->j_commit_interval/HZ seconds, it's safe to do a fast commit; otherwise do a full commit. Cheers, - Ted ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [External] Re: [PATCH RESEND] ext4:fix different behavior of fsync when use fast commit 2022-01-06 3:22 ` Theodore Ts'o @ 2022-01-07 8:49 ` Xin Yin 0 siblings, 0 replies; 3+ messages in thread From: Xin Yin @ 2022-01-07 8:49 UTC (permalink / raw) To: Theodore Ts'o; +Cc: harshadshirwadkar, linux-ext4, linux-kernel Thanks for the explanation and direction , I will do another fix for this issue. Best Regards, Xin Yin On Thu, Jan 6, 2022 at 11:22 AM Theodore Ts'o <tytso@mit.edu> wrote: > > On Fri, Dec 24, 2021 at 02:57:28PM +0800, Xin Yin wrote: > > For the follow test 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. > > The problem is that your proposed fix: > > > diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c > > index 3deb97b22ca4..4b843648ffe5 100644 > > --- a/fs/ext4/fast_commit.c > > +++ b/fs/ext4/fast_commit.c > > @@ -423,7 +423,7 @@ void __ext4_fc_track_create(handle_t *handle, struct inode *inode, > > args.op = EXT4_FC_TAG_CREAT; > > > > ret = ext4_fc_track_template(handle, inode, __track_dentry_update, > > - (void *)&args, 0); > > + (void *)&args, 1); > > trace_ext4_fc_track_create(inode, dentry, ret); > > } > > affects both file creations as well as directory creations (mkdir). > Putting the inode on the fast commit list is something that is meant > for files, and means that on a fast commit we need to force the data > blocks out. So it seems that isn't the right fix for the problem. > > Why do something really simple? Look at the parent directory's inode, > and check its i_sync_tid. If it's not equal to > handle->h_transaction->t_tid, then it's safe to do the fast commit. > If it's equal to the current transaction, we can either force a full > commit. > > Optionally, in the case where i_sync_tid == current tid, since there's > a chance that the parent directory's inode could have been freshly > fetched from disk (see __ext4_iget() in fs/ext4/inode.c), we could > compare its i_crtime against ktime_get_real_seconds(), and if the > inode was created in the last 2*journal->j_commit_interval/HZ seconds, > it's safe to do a fast commit; otherwise do a full commit. > > Cheers, > > - Ted ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-01-07 8:49 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-12-24 6:57 [PATCH RESEND] ext4:fix different behavior of fsync when use fast commit Xin Yin 2022-01-06 3:22 ` Theodore Ts'o 2022-01-07 8:49 ` [External] " Xin Yin
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.