diff options
| author | Zhang Yi <yi.zhang@huawei.com> | 2026-09-03 20:35:35 +0800 |
|---|---|---|
| committer | Theodore Ts'o <tytso@mit.edu> | 2026-10-08 11:11:25 -0400 |
| commit | 61bf54b10d4fdcb32ce0cd625dfc14e7f2c02359 (patch) | |
| tree | e419300b4c3de3af6ade91f5792700c7aa9047ee /include/uapi/linux/errqueue.h | |
| parent | b9dc57ecc8a5ba34299e737d4954c1df54f16ea8 (diff) | |
| download | linux-next-61bf54b10d4fdcb32ce0cd625dfc14e7f2c02359.tar.gz linux-next-61bf54b10d4fdcb32ce0cd625dfc14e7f2c02359.zip | |
ext4: advance i_disksize to i_size upon disksize-grow I/O completion
When the disksize-grow-pending zeroed EOF I/O completes, i_disksize has
to be advanced. Advancing it only to the end of that specific I/O would
discard any later i_disksize updates from concurrent fallocate or
similar operations, causing filesystem inconsistency.
Scanning dirty or writeback folios beyond the current position to
compute a safe advance target is expensive and racy with concurrent
fallocate, so instead advance i_disksize directly to i_size. This may
expose zeroed data (not stale data) after crash recovery when dirty data
in the range is not yet on disk, but only for unaligned append writes,
which is deemed acceptable.
To support this, teach ext4_iomap_wb_update_disksize() to take an
is_disksize_grow flag and advance i_disksize to i_size when set, and
have ext4_iomap_finish_ioend() pass the flag based on the
EXT4_IOMAP_IOEND_DISKSIZE_GROW_IO tag of the completing ioend.
Note that EXT4_STATE_DISKSIZE_GROW_PENDING is not set for now, and it
will be set after everthing is done.
Suggested-by: Jan Kara <jack@suse.cz>
Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
Link: https://patch.msgid.link/20260903123543.2302999-24-yi.zhang@huaweicloud.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Diffstat (limited to 'include/uapi/linux/errqueue.h')
0 files changed, 0 insertions, 0 deletions
