ext4 fast commit API cleanup
Status from this message: Applied, thanks!
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v2 Latest4 patches 4 repliesApplied
- v13 patches 1 replySuperseded
Changes in v2 from the cover letter
---------------
- In the V1 of the patch series, there's performance regression. With this patch series, we lock the entire file system from starting any new handles during (which ensures consistency at the cost of performance). What we ideally want to do is to lock individual inodes from starting new updates during a commit. To do so, the V2 of this patch series retains the infrastructure of inode level transactions (ext4_fc_start/stop_update()). In future (not in this series), we would build on this infrastructure to lock individual inodes and drop the file system level locking during the commit path.
Patches in v2 Applied
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/4 | ext4: use ext4_journal_start/stop for fast commit transactionsfs/ fs/ fs/ +3 more | +4 | 0 replies | |
| 2/4 | ext4: drop ineligible txn start stop APIsfs/ fs/ fs/ +2 more | +20 | 0 replies | |
| 3/4 | ext4: simplify updating of fast commit statsfs/ fs/ fs/ | +68 | 0 replies | |
| 4/4 | ext4: update fast commit TODOsfs/ | +6 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.
Cover letter [PATCH v2 0/4] ext4 fast commit API cleanup
This patch series fixes up fast commit APIs. There are NO on-disk format changes introduced in this series. The main contribution of the series is that it drops fast commit specific transaction APIs and makes fast commits work with journal transaction APIs of JBD2 journalling system. With these changes, a fast commit eligible transaction is simply enclosed in calls to "jbd2_journal_start()" and "jbd2_journal_stop()". If the update that is being performed is fast commit ineligible, one must simply call ext4_fc_mark_ineligible() after starting a transaction using "jbd2_journal_start()". The last patch in the series simplifies fast commit stats recording by moving it to a different function.
I verified that the patch series introduces no regressions in "quick" and "log" groups when "fast_commit" feature is enabled.
Changes from V1:
---------------
- In the V1 of the patch series, there's performance regression. With this patch series, we lock the entire file system from starting any new handles during (which ensures consistency at the cost of performance). What we ideally want to do is to lock individual inodes from starting new updates during a commit. To do so, the V2 of this patch series retains the infrastructure of inode level transactions (ext4_fc_start/stop_update()). In future (not in this series), we would build on this infrastructure to lock individual inodes and drop the file system level locking during the commit path.
Harshad Shirwadkar (4):
ext4: use ext4_journal_start/stop for fast commit transactions
ext4: drop ineligible txn start stop APIs
ext4: simplify updating of fast commit stats
ext4: update fast commit TODOs
fs/ext4/acl.c | 2 - fs/ext4/ext4.h | 7 +- fs/ext4/extents.c | 9 +- fs/ext4/fast_commit.c | 188 ++++++++++++++++-------------------------- fs/ext4/fast_commit.h | 27 +++--- fs/ext4/file.c | 4 - fs/ext4/inode.c | 7 +- fs/ext4/ioctl.c | 13 +-- fs/ext4/super.c | 1 - fs/jbd2/journal.c | 2 + 10 files changed, 96 insertions(+), 164 deletions(-)
Signature · 1 line
2.34.1.307.g9b7440fafd-goog