mbox series

[0/7] ext4: Cleanup data=journal writeback path

Message ID 20230111152736.9608-1-jack@suse.cz
Headers show
Series ext4: Cleanup data=journal writeback path | expand

Message

Jan Kara Jan. 11, 2023, 3:43 p.m. UTC 
Hello,

this patch series implements promised cleanup of ext4 data=journal writeback
path. That way we can get rid of last remnants of old support for .writepage
callback and mostly unify this writeback path with standard data handling
modes. We also update some of the stale comments regarding data=journal mode
along the way.

Note that patch 3 (ext4: Mark page for delayed dirtying only if it is pinned)
currently breaks somewhat the data=journal guarantees if mapped page cache is
used as a buffer for direct IO read because that path does not pin pages yet
(David Howels is working on it). But I figured this is not a huge deal for a
cornercase usecase of a cornercase configuration and keeping marking page for
delayed dirtying unconditionally is problematic as checkpointing dirties the
page as well so it is effectively permanently added to the journal. It was
problematic already in the past and happened to work only by luck.

								Honza

Comments

Theodore Ts'o Feb. 19, 2023, 5:40 a.m. UTC | #1 
On Wed, 11 Jan 2023 16:43:24 +0100, Jan Kara wrote:
> this patch series implements promised cleanup of ext4 data=journal writeback
> path. That way we can get rid of last remnants of old support for .writepage
> callback and mostly unify this writeback path with standard data handling
> modes. We also update some of the stale comments regarding data=journal mode
> along the way.
> 
> Note that patch 3 (ext4: Mark page for delayed dirtying only if it is pinned)
> currently breaks somewhat the data=journal guarantees if mapped page cache is
> used as a buffer for direct IO read because that path does not pin pages yet
> (David Howels is working on it). But I figured this is not a huge deal for a
> cornercase usecase of a cornercase configuration and keeping marking page for
> delayed dirtying unconditionally is problematic as checkpointing dirties the
> page as well so it is effectively permanently added to the journal. It was
> problematic already in the past and happened to work only by luck.
> 
> [...]

Applied, thanks!

[1/7] ext4: Update stale comment about write constraints
      commit: d399906a1bd04c3fbc5bca9057ce992dc9b9e036
[2/7] ext4: Use nr_to_write directly in mpage_prepare_extent_to_map()
      commit: 726432969963b16f817566715b0c7ec537d0283b
[3/7] ext4: Mark page for delayed dirtying only if it is pinned
      commit: 71ace6bd0d47b09d6130014d70f87fcff5ae3e36
[4/7] ext4: Don't unlock page in ext4_bio_write_page()
      commit: 0bcd54cf93e0dcefd121368fa32a478df2c86398
[5/7] ext4: Move page unlocking out of mpage_submit_page()
      commit: 9ff6a9153c8f8a08eb60e0740c32e08cef88545c
[6/7] ext4: Move mpage_page_done() calls after error handling
      commit: b4d26e70a7556ca723d31ac0c6bace0d1ab932b5
[7/7] ext4: Convert data=journal writeback to use ext4_writepages()
      commit: 9b18c23c131ae6a335ef7aa6bf53f1d27a667ed1

Best regards,