From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: xiaohui li <lixiaohui1@xiaomi.corp-partner.google.com>
Cc: Harshad Shirwadkar <harshadshirwadkar@gmail.com>,
linux-ext4@vger.kernel.org
Subject: Re: [PATCH v3 09/13] ext4: fast-commit commit path changes
Date: Wed, 23 Oct 2019 08:44:02 -0400 [thread overview]
Message-ID: <20191023124402.GA31059@mit.edu> (raw)
In-Reply-To: <CAAJeciXQiE022GqcsTr35jSqjA6eH+zBS2KNvDPj5PovButdYA@mail.gmail.com>
On Wed, Oct 23, 2019 at 04:58:47PM +0800, xiaohui li wrote:
> why not let fsync handle enjoy one transaction exclusively ?
> that is to say, in this transaction, there is only one handle which is
> generated in one file's fsync path .
There is only one handle which is generated in one file's fsync path.
That isn't the problem. (If it were that simple, we would have done
it a long time ago.)
The problem is that there may have been other handles that have been
started before the fsync transaction, and these handles will have
already made changes to the file system. Worse, some of those handles
may have made changes in the same metadata blocks which the fsync
operation needs to modify.
For example, suppose we are three seconds into the current
transaction, with potentially hundreds of handles that have already
been started and finished --- but not yet committed, because the
current transaction hasn't closed. All of those handles have already
been attached to the current transaction, and they can't be ignored.
The fast commit patch set deals with this by using part of the journal
for a "fast commit journal" where we essentially are doing a very
simplified logical journal. It doesn't handle all cases, and there
will be situations where we will need to fall back to the physical
journalling techniques used in ext4 today. For example, if the file
has been truncated, and then a single 4k block is written, and then
the file gets fsync'ed, we won't be able to use the fast commit
logical journal. Fortunately, the common case which compromises well
over 99% of most workloads are much simpler to handle, and these can
be handled via the fast commit patch.
The fast commit approach is a simplified version of the idea proposed
by Daejun Park and Dungkun Shih from the Sungkyunkwan University in
Korea, and which were presented in the paper "iJournaling:
Fine-Grained Journaling for Improving the Latency of Fsync System
Call[1]", presented at the Usenix Annual Technical Conference in 2017.
[1] https://www.usenix.org/conference/atc17/technical-sessions/presentation/park
Cheers,
- Ted
next prev parent reply other threads:[~2019-10-23 12:44 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-01 7:40 [PATCH v3 00/13] ext4: add fast commit support Harshad Shirwadkar
2019-10-01 7:40 ` [PATCH v3 01/13] ext4: add handling for extended mount options Harshad Shirwadkar
2019-10-16 2:14 ` Theodore Y. Ts'o
2019-10-21 20:41 ` harshad shirwadkar
2019-10-01 7:40 ` [PATCH v3 02/13] jbd2: fast commit setup and enable Harshad Shirwadkar
2019-10-16 13:03 ` Theodore Y. Ts'o
2019-10-01 7:40 ` [PATCH v3 03/13] jbd2: fast-commit commit path changes Harshad Shirwadkar
2019-10-16 16:38 ` Theodore Y. Ts'o
2019-10-01 7:40 ` [PATCH v3 04/13] jbd2: fast-commit commit path new APIs Harshad Shirwadkar
2019-10-16 17:20 ` Theodore Y. Ts'o
2019-10-01 7:40 ` [PATCH v3 05/13] jbd2: fast-commit recovery path changes Harshad Shirwadkar
2019-10-16 17:30 ` Theodore Y. Ts'o
2019-10-22 0:51 ` harshad shirwadkar
2019-10-01 7:40 ` [PATCH v3 06/13] ext4: add fields that are needed to track changed files Harshad Shirwadkar
2019-10-16 18:26 ` Theodore Y. Ts'o
2019-10-01 7:40 ` [PATCH v3 07/13] ext4: track changed files for fast commit Harshad Shirwadkar
2019-10-16 20:26 ` Theodore Y. Ts'o
2019-10-01 7:40 ` [PATCH v3 08/13] ext4: fast-commit commit range tracking Harshad Shirwadkar
2019-10-16 21:36 ` Theodore Y. Ts'o
2019-10-30 5:12 ` harshad shirwadkar
2019-10-01 7:40 ` [PATCH v3 09/13] ext4: fast-commit commit path changes Harshad Shirwadkar
2019-10-16 22:45 ` Theodore Y. Ts'o
[not found] ` <CAAJeciXQiE022GqcsTr35jSqjA6eH+zBS2KNvDPj5PovButdYA@mail.gmail.com>
2019-10-23 12:44 ` Theodore Y. Ts'o [this message]
2019-10-01 7:40 ` [PATCH v3 10/13] ext4: fast-commit recovery " Harshad Shirwadkar
2019-10-18 2:07 ` Theodore Y. Ts'o
2019-10-01 7:41 ` [PATCH v3 11/13] ext4: add support for asynchronous fast commits Harshad Shirwadkar
2019-10-25 6:28 ` Xiaoguang Wang
2019-10-01 7:41 ` [PATCH v3 12/13] docs: Add fast commit documentation Harshad Shirwadkar
2019-10-18 1:56 ` Theodore Y. Ts'o
2019-10-18 4:51 ` Andreas Dilger
2019-10-18 13:28 ` Theodore Y. Ts'o
2019-10-31 18:53 ` Andreas Dilger
2019-10-31 5:34 ` harshad shirwadkar
2019-10-31 6:41 ` harshad shirwadkar
2019-10-04 19:12 ` [PATCH v3 00/13] ext4: add fast commit support Theodore Y. Ts'o
2019-10-04 20:11 ` harshad shirwadkar
[not found] <1571900042725.99617@xiaomi.com>
2019-10-24 20:18 ` [PATCH v3 09/13] ext4: fast-commit commit path changes Theodore Y. Ts'o
[not found] ` <1572349386604.43878@xiaomi.com>
2019-10-29 21:35 ` Theodore Y. Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191023124402.GA31059@mit.edu \
--to=tytso@mit.edu \
--cc=harshadshirwadkar@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=lixiaohui1@xiaomi.corp-partner.google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).