Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28 |
|
#
6a911b88 |
| 15-Apr-2024 |
Qu Wenruo <wqu@suse.com> |
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated:
item 16 key (258 EXTENT_DATA 2682880) itemoff 15305 itemsize 53 generation 9 type 1 (regular) extent data disk byte 1378414592 nr 462848 extent data offset 0 nr 462848 ram 2097152 extent compression 0 (none)
Note that file extent item is not a compressed one, but its ram_bytes is way larger than its disk_num_bytes.
According to btrfs on-disk scheme, ram_bytes should match disk_num_bytes if it's not a compressed one.
[CAUSE] Since commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit"), for partial dio writes, we would split the ordered extent.
However the function btrfs_split_ordered_extent() doesn't update the ram_bytes even it has already shrunk the disk_num_bytes.
Originally the function btrfs_split_ordered_extent() is only introduced for zoned devices in commit d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent"), but later commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit") makes non-zoned btrfs affected.
Thankfully for un-compressed file extent, we do not really utilize the ram_bytes member, thus it won't cause any real problem.
[FIX] Also update btrfs_ordered_extent::ram_bytes inside btrfs_split_ordered_extent().
Fixes: d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28 |
|
#
6a911b88 |
| 15-Apr-2024 |
Qu Wenruo <wqu@suse.com> |
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated:
item 16 key (258 EXTENT_DATA 2682880) itemoff 15305 itemsize 53 generation 9 type 1 (regular) extent data disk byte 1378414592 nr 462848 extent data offset 0 nr 462848 ram 2097152 extent compression 0 (none)
Note that file extent item is not a compressed one, but its ram_bytes is way larger than its disk_num_bytes.
According to btrfs on-disk scheme, ram_bytes should match disk_num_bytes if it's not a compressed one.
[CAUSE] Since commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit"), for partial dio writes, we would split the ordered extent.
However the function btrfs_split_ordered_extent() doesn't update the ram_bytes even it has already shrunk the disk_num_bytes.
Originally the function btrfs_split_ordered_extent() is only introduced for zoned devices in commit d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent"), but later commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit") makes non-zoned btrfs affected.
Thankfully for un-compressed file extent, we do not really utilize the ram_bytes member, thus it won't cause any real problem.
[FIX] Also update btrfs_ordered_extent::ram_bytes inside btrfs_split_ordered_extent().
Fixes: d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28 |
|
#
6a911b88 |
| 15-Apr-2024 |
Qu Wenruo <wqu@suse.com> |
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated:
item 16 key (258 EXTENT_DATA 2682880) itemoff 15305 itemsize 53 generation 9 type 1 (regular) extent data disk byte 1378414592 nr 462848 extent data offset 0 nr 462848 ram 2097152 extent compression 0 (none)
Note that file extent item is not a compressed one, but its ram_bytes is way larger than its disk_num_bytes.
According to btrfs on-disk scheme, ram_bytes should match disk_num_bytes if it's not a compressed one.
[CAUSE] Since commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit"), for partial dio writes, we would split the ordered extent.
However the function btrfs_split_ordered_extent() doesn't update the ram_bytes even it has already shrunk the disk_num_bytes.
Originally the function btrfs_split_ordered_extent() is only introduced for zoned devices in commit d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent"), but later commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit") makes non-zoned btrfs affected.
Thankfully for un-compressed file extent, we do not really utilize the ram_bytes member, thus it won't cause any real problem.
[FIX] Also update btrfs_ordered_extent::ram_bytes inside btrfs_split_ordered_extent().
Fixes: d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28 |
|
#
6a911b88 |
| 15-Apr-2024 |
Qu Wenruo <wqu@suse.com> |
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated:
item 16 key (258 EXTENT_DATA 2682880) itemoff 15305 itemsize 53 generation 9 type 1 (regular) extent data disk byte 1378414592 nr 462848 extent data offset 0 nr 462848 ram 2097152 extent compression 0 (none)
Note that file extent item is not a compressed one, but its ram_bytes is way larger than its disk_num_bytes.
According to btrfs on-disk scheme, ram_bytes should match disk_num_bytes if it's not a compressed one.
[CAUSE] Since commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit"), for partial dio writes, we would split the ordered extent.
However the function btrfs_split_ordered_extent() doesn't update the ram_bytes even it has already shrunk the disk_num_bytes.
Originally the function btrfs_split_ordered_extent() is only introduced for zoned devices in commit d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent"), but later commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit") makes non-zoned btrfs affected.
Thankfully for un-compressed file extent, we do not really utilize the ram_bytes member, thus it won't cause any real problem.
[FIX] Also update btrfs_ordered_extent::ram_bytes inside btrfs_split_ordered_extent().
Fixes: d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28 |
|
#
6a911b88 |
| 15-Apr-2024 |
Qu Wenruo <wqu@suse.com> |
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated:
item 16 key (258 EXTENT_DATA 2682880) itemoff 15305 itemsize 53 generation 9 type 1 (regular) extent data disk byte 1378414592 nr 462848 extent data offset 0 nr 462848 ram 2097152 extent compression 0 (none)
Note that file extent item is not a compressed one, but its ram_bytes is way larger than its disk_num_bytes.
According to btrfs on-disk scheme, ram_bytes should match disk_num_bytes if it's not a compressed one.
[CAUSE] Since commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit"), for partial dio writes, we would split the ordered extent.
However the function btrfs_split_ordered_extent() doesn't update the ram_bytes even it has already shrunk the disk_num_bytes.
Originally the function btrfs_split_ordered_extent() is only introduced for zoned devices in commit d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent"), but later commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit") makes non-zoned btrfs affected.
Thankfully for un-compressed file extent, we do not really utilize the ram_bytes member, thus it won't cause any real problem.
[FIX] Also update btrfs_ordered_extent::ram_bytes inside btrfs_split_ordered_extent().
Fixes: d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28 |
|
#
6a911b88 |
| 15-Apr-2024 |
Qu Wenruo <wqu@suse.com> |
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated:
item 16 key (258 EXTENT_DATA 2682880) itemoff 15305 itemsize 53 generation 9 type 1 (regular) extent data disk byte 1378414592 nr 462848 extent data offset 0 nr 462848 ram 2097152 extent compression 0 (none)
Note that file extent item is not a compressed one, but its ram_bytes is way larger than its disk_num_bytes.
According to btrfs on-disk scheme, ram_bytes should match disk_num_bytes if it's not a compressed one.
[CAUSE] Since commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit"), for partial dio writes, we would split the ordered extent.
However the function btrfs_split_ordered_extent() doesn't update the ram_bytes even it has already shrunk the disk_num_bytes.
Originally the function btrfs_split_ordered_extent() is only introduced for zoned devices in commit d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent"), but later commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit") makes non-zoned btrfs affected.
Thankfully for un-compressed file extent, we do not really utilize the ram_bytes member, thus it won't cause any real problem.
[FIX] Also update btrfs_ordered_extent::ram_bytes inside btrfs_split_ordered_extent().
Fixes: d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28 |
|
#
6a911b88 |
| 15-Apr-2024 |
Qu Wenruo <wqu@suse.com> |
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated:
item 16 key (258 EXTENT_DATA 2682880) itemoff 15305 itemsize 53 generation 9 type 1 (regular) extent data disk byte 1378414592 nr 462848 extent data offset 0 nr 462848 ram 2097152 extent compression 0 (none)
Note that file extent item is not a compressed one, but its ram_bytes is way larger than its disk_num_bytes.
According to btrfs on-disk scheme, ram_bytes should match disk_num_bytes if it's not a compressed one.
[CAUSE] Since commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit"), for partial dio writes, we would split the ordered extent.
However the function btrfs_split_ordered_extent() doesn't update the ram_bytes even it has already shrunk the disk_num_bytes.
Originally the function btrfs_split_ordered_extent() is only introduced for zoned devices in commit d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent"), but later commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit") makes non-zoned btrfs affected.
Thankfully for un-compressed file extent, we do not really utilize the ram_bytes member, thus it won't cause any real problem.
[FIX] Also update btrfs_ordered_extent::ram_bytes inside btrfs_split_ordered_extent().
Fixes: d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28 |
|
#
6a911b88 |
| 15-Apr-2024 |
Qu Wenruo <wqu@suse.com> |
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated:
item 16 key (258 EXTENT_DATA 2682880) itemoff 15305 itemsize 53 generation 9 type 1 (regular) extent data disk byte 1378414592 nr 462848 extent data offset 0 nr 462848 ram 2097152 extent compression 0 (none)
Note that file extent item is not a compressed one, but its ram_bytes is way larger than its disk_num_bytes.
According to btrfs on-disk scheme, ram_bytes should match disk_num_bytes if it's not a compressed one.
[CAUSE] Since commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit"), for partial dio writes, we would split the ordered extent.
However the function btrfs_split_ordered_extent() doesn't update the ram_bytes even it has already shrunk the disk_num_bytes.
Originally the function btrfs_split_ordered_extent() is only introduced for zoned devices in commit d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent"), but later commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit") makes non-zoned btrfs affected.
Thankfully for un-compressed file extent, we do not really utilize the ram_bytes member, thus it won't cause any real problem.
[FIX] Also update btrfs_ordered_extent::ram_bytes inside btrfs_split_ordered_extent().
Fixes: d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28 |
|
#
6a911b88 |
| 15-Apr-2024 |
Qu Wenruo <wqu@suse.com> |
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated:
item 16 key (258 EXTENT_DATA 2682880) itemoff 15305 itemsize 53 generation 9 type 1 (regular) extent data disk byte 1378414592 nr 462848 extent data offset 0 nr 462848 ram 2097152 extent compression 0 (none)
Note that file extent item is not a compressed one, but its ram_bytes is way larger than its disk_num_bytes.
According to btrfs on-disk scheme, ram_bytes should match disk_num_bytes if it's not a compressed one.
[CAUSE] Since commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit"), for partial dio writes, we would split the ordered extent.
However the function btrfs_split_ordered_extent() doesn't update the ram_bytes even it has already shrunk the disk_num_bytes.
Originally the function btrfs_split_ordered_extent() is only introduced for zoned devices in commit d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent"), but later commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit") makes non-zoned btrfs affected.
Thankfully for un-compressed file extent, we do not really utilize the ram_bytes member, thus it won't cause any real problem.
[FIX] Also update btrfs_ordered_extent::ram_bytes inside btrfs_split_ordered_extent().
Fixes: d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28 |
|
#
6a911b88 |
| 15-Apr-2024 |
Qu Wenruo <wqu@suse.com> |
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated:
item 16 key (258 EXTENT_DATA 2682880) itemoff 15305 itemsize 53 generation 9 type 1 (regular) extent data disk byte 1378414592 nr 462848 extent data offset 0 nr 462848 ram 2097152 extent compression 0 (none)
Note that file extent item is not a compressed one, but its ram_bytes is way larger than its disk_num_bytes.
According to btrfs on-disk scheme, ram_bytes should match disk_num_bytes if it's not a compressed one.
[CAUSE] Since commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit"), for partial dio writes, we would split the ordered extent.
However the function btrfs_split_ordered_extent() doesn't update the ram_bytes even it has already shrunk the disk_num_bytes.
Originally the function btrfs_split_ordered_extent() is only introduced for zoned devices in commit d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent"), but later commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit") makes non-zoned btrfs affected.
Thankfully for un-compressed file extent, we do not really utilize the ram_bytes member, thus it won't cause any real problem.
[FIX] Also update btrfs_ordered_extent::ram_bytes inside btrfs_split_ordered_extent().
Fixes: d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28 |
|
#
6a911b88 |
| 15-Apr-2024 |
Qu Wenruo <wqu@suse.com> |
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated:
item 16 key (258 EXTENT_DATA 2682880) itemoff 15305 itemsize 53 generation 9 type 1 (regular) extent data disk byte 1378414592 nr 462848 extent data offset 0 nr 462848 ram 2097152 extent compression 0 (none)
Note that file extent item is not a compressed one, but its ram_bytes is way larger than its disk_num_bytes.
According to btrfs on-disk scheme, ram_bytes should match disk_num_bytes if it's not a compressed one.
[CAUSE] Since commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit"), for partial dio writes, we would split the ordered extent.
However the function btrfs_split_ordered_extent() doesn't update the ram_bytes even it has already shrunk the disk_num_bytes.
Originally the function btrfs_split_ordered_extent() is only introduced for zoned devices in commit d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent"), but later commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit") makes non-zoned btrfs affected.
Thankfully for un-compressed file extent, we do not really utilize the ram_bytes member, thus it won't cause any real problem.
[FIX] Also update btrfs_ordered_extent::ram_bytes inside btrfs_split_ordered_extent().
Fixes: d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28 |
|
#
6a911b88 |
| 15-Apr-2024 |
Qu Wenruo <wqu@suse.com> |
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated:
item 16 key (258 EXTENT_DATA 2682880) itemoff 15305 itemsize 53 generation 9 type 1 (regular) extent data disk byte 1378414592 nr 462848 extent data offset 0 nr 462848 ram 2097152 extent compression 0 (none)
Note that file extent item is not a compressed one, but its ram_bytes is way larger than its disk_num_bytes.
According to btrfs on-disk scheme, ram_bytes should match disk_num_bytes if it's not a compressed one.
[CAUSE] Since commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit"), for partial dio writes, we would split the ordered extent.
However the function btrfs_split_ordered_extent() doesn't update the ram_bytes even it has already shrunk the disk_num_bytes.
Originally the function btrfs_split_ordered_extent() is only introduced for zoned devices in commit d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent"), but later commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit") makes non-zoned btrfs affected.
Thankfully for un-compressed file extent, we do not really utilize the ram_bytes member, thus it won't cause any real problem.
[FIX] Also update btrfs_ordered_extent::ram_bytes inside btrfs_split_ordered_extent().
Fixes: d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28 |
|
#
6a911b88 |
| 15-Apr-2024 |
Qu Wenruo <wqu@suse.com> |
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated:
item 16 key (258 EXTENT_DATA 2682880) itemoff 15305 itemsize 53 generation 9 type 1 (regular) extent data disk byte 1378414592 nr 462848 extent data offset 0 nr 462848 ram 2097152 extent compression 0 (none)
Note that file extent item is not a compressed one, but its ram_bytes is way larger than its disk_num_bytes.
According to btrfs on-disk scheme, ram_bytes should match disk_num_bytes if it's not a compressed one.
[CAUSE] Since commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit"), for partial dio writes, we would split the ordered extent.
However the function btrfs_split_ordered_extent() doesn't update the ram_bytes even it has already shrunk the disk_num_bytes.
Originally the function btrfs_split_ordered_extent() is only introduced for zoned devices in commit d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent"), but later commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit") makes non-zoned btrfs affected.
Thankfully for un-compressed file extent, we do not really utilize the ram_bytes member, thus it won't cause any real problem.
[FIX] Also update btrfs_ordered_extent::ram_bytes inside btrfs_split_ordered_extent().
Fixes: d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28 |
|
#
6a911b88 |
| 15-Apr-2024 |
Qu Wenruo <wqu@suse.com> |
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated:
item 16 key (258 EXTENT_DATA 2682880) itemoff 15305 itemsize 53 generation 9 type 1 (regular) extent data disk byte 1378414592 nr 462848 extent data offset 0 nr 462848 ram 2097152 extent compression 0 (none)
Note that file extent item is not a compressed one, but its ram_bytes is way larger than its disk_num_bytes.
According to btrfs on-disk scheme, ram_bytes should match disk_num_bytes if it's not a compressed one.
[CAUSE] Since commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit"), for partial dio writes, we would split the ordered extent.
However the function btrfs_split_ordered_extent() doesn't update the ram_bytes even it has already shrunk the disk_num_bytes.
Originally the function btrfs_split_ordered_extent() is only introduced for zoned devices in commit d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent"), but later commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit") makes non-zoned btrfs affected.
Thankfully for un-compressed file extent, we do not really utilize the ram_bytes member, thus it won't cause any real problem.
[FIX] Also update btrfs_ordered_extent::ram_bytes inside btrfs_split_ordered_extent().
Fixes: d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28 |
|
#
6a911b88 |
| 15-Apr-2024 |
Qu Wenruo <wqu@suse.com> |
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated:
item 16 key (258 EXTENT_DATA 2682880) itemoff 15305 itemsize 53 generation 9 type 1 (regular) extent data disk byte 1378414592 nr 462848 extent data offset 0 nr 462848 ram 2097152 extent compression 0 (none)
Note that file extent item is not a compressed one, but its ram_bytes is way larger than its disk_num_bytes.
According to btrfs on-disk scheme, ram_bytes should match disk_num_bytes if it's not a compressed one.
[CAUSE] Since commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit"), for partial dio writes, we would split the ordered extent.
However the function btrfs_split_ordered_extent() doesn't update the ram_bytes even it has already shrunk the disk_num_bytes.
Originally the function btrfs_split_ordered_extent() is only introduced for zoned devices in commit d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent"), but later commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit") makes non-zoned btrfs affected.
Thankfully for un-compressed file extent, we do not really utilize the ram_bytes member, thus it won't cause any real problem.
[FIX] Also update btrfs_ordered_extent::ram_bytes inside btrfs_split_ordered_extent().
Fixes: d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28 |
|
#
6a911b88 |
| 15-Apr-2024 |
Qu Wenruo <wqu@suse.com> |
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated:
item 16 key (258 EXTENT_DATA 2682880) itemoff 15305 itemsize 53 generation 9 type 1 (regular) extent data disk byte 1378414592 nr 462848 extent data offset 0 nr 462848 ram 2097152 extent compression 0 (none)
Note that file extent item is not a compressed one, but its ram_bytes is way larger than its disk_num_bytes.
According to btrfs on-disk scheme, ram_bytes should match disk_num_bytes if it's not a compressed one.
[CAUSE] Since commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit"), for partial dio writes, we would split the ordered extent.
However the function btrfs_split_ordered_extent() doesn't update the ram_bytes even it has already shrunk the disk_num_bytes.
Originally the function btrfs_split_ordered_extent() is only introduced for zoned devices in commit d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent"), but later commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit") makes non-zoned btrfs affected.
Thankfully for un-compressed file extent, we do not really utilize the ram_bytes member, thus it won't cause any real problem.
[FIX] Also update btrfs_ordered_extent::ram_bytes inside btrfs_split_ordered_extent().
Fixes: d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28 |
|
#
6a911b88 |
| 15-Apr-2024 |
Qu Wenruo <wqu@suse.com> |
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated:
item 16 key (258 EXTENT_DATA 2682880) itemoff 15305 itemsize 53 generation 9 type 1 (regular) extent data disk byte 1378414592 nr 462848 extent data offset 0 nr 462848 ram 2097152 extent compression 0 (none)
Note that file extent item is not a compressed one, but its ram_bytes is way larger than its disk_num_bytes.
According to btrfs on-disk scheme, ram_bytes should match disk_num_bytes if it's not a compressed one.
[CAUSE] Since commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit"), for partial dio writes, we would split the ordered extent.
However the function btrfs_split_ordered_extent() doesn't update the ram_bytes even it has already shrunk the disk_num_bytes.
Originally the function btrfs_split_ordered_extent() is only introduced for zoned devices in commit d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent"), but later commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit") makes non-zoned btrfs affected.
Thankfully for un-compressed file extent, we do not really utilize the ram_bytes member, thus it won't cause any real problem.
[FIX] Also update btrfs_ordered_extent::ram_bytes inside btrfs_split_ordered_extent().
Fixes: d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28 |
|
#
6a911b88 |
| 15-Apr-2024 |
Qu Wenruo <wqu@suse.com> |
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated
btrfs: set correct ram_bytes when splitting ordered extent
commit 63a6ce5a1a6261e4c70bad2b55c4e0de8da4762e upstream.
[BUG] When running generic/287, the following file extent items can be generated:
item 16 key (258 EXTENT_DATA 2682880) itemoff 15305 itemsize 53 generation 9 type 1 (regular) extent data disk byte 1378414592 nr 462848 extent data offset 0 nr 462848 ram 2097152 extent compression 0 (none)
Note that file extent item is not a compressed one, but its ram_bytes is way larger than its disk_num_bytes.
According to btrfs on-disk scheme, ram_bytes should match disk_num_bytes if it's not a compressed one.
[CAUSE] Since commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit"), for partial dio writes, we would split the ordered extent.
However the function btrfs_split_ordered_extent() doesn't update the ram_bytes even it has already shrunk the disk_num_bytes.
Originally the function btrfs_split_ordered_extent() is only introduced for zoned devices in commit d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent"), but later commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit") makes non-zoned btrfs affected.
Thankfully for un-compressed file extent, we do not really utilize the ram_bytes member, thus it won't cause any real problem.
[FIX] Also update btrfs_ordered_extent::ram_bytes inside btrfs_split_ordered_extent().
Fixes: d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4 |
|
#
18234915 |
| 01-Dec-2023 |
Boris Burkov <boris@bur.io> |
btrfs: fix qgroup_free_reserved_data int overflow
commit 9e65bfca24cf1d77e4a5c7a170db5867377b3fe7 upstream.
The reserved data counter and input parameter is a u64, but we inadvertently accumulate i
btrfs: fix qgroup_free_reserved_data int overflow
commit 9e65bfca24cf1d77e4a5c7a170db5867377b3fe7 upstream.
The reserved data counter and input parameter is a u64, but we inadvertently accumulate it in an int. Overflowing that int results in freeing the wrong amount of data and breaking reserve accounting.
Unfortunately, this overflow rot spreads from there, as the qgroup release/free functions rely on returning an int to take advantage of negative values for error codes.
Therefore, the full fix is to return the "released" or "freed" amount by a u64 argument and to return 0 or negative error code via the return value.
Most of the call sites simply ignore the return value, though some of them handle the error and count the returned bytes. Change all of them accordingly.
CC: stable@vger.kernel.org # 6.1+ Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Boris Burkov <boris@bur.io> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
14570dfa |
| 01-Dec-2023 |
Boris Burkov <boris@bur.io> |
btrfs: free qgroup reserve when ORDERED_IOERR is set
commit f63e1164b90b385cd832ff0fdfcfa76c3cc15436 upstream.
An ordered extent completing is a critical moment in qgroup reserve handling, as the o
btrfs: free qgroup reserve when ORDERED_IOERR is set
commit f63e1164b90b385cd832ff0fdfcfa76c3cc15436 upstream.
An ordered extent completing is a critical moment in qgroup reserve handling, as the ownership of the reservation is handed off from the ordered extent to the delayed ref. In the happy path we release (unlock) but do not free (decrement counter) the reservation, and the delayed ref drives the free. However, on an error, we don't create a delayed ref, since there is no ref to add. Therefore, free on the error path.
CC: stable@vger.kernel.org # 6.1+ Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Boris Burkov <boris@bur.io> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48 |
|
#
4ca8e03c |
| 24-Aug-2023 |
Josef Bacik <josef@toxicpanda.com> |
btrfs: check for BTRFS_FS_ERROR in pending ordered assert
If we do fast tree logging we increment a counter on the current transaction for every ordered extent we need to wait for. This means we ex
btrfs: check for BTRFS_FS_ERROR in pending ordered assert
If we do fast tree logging we increment a counter on the current transaction for every ordered extent we need to wait for. This means we expect the transaction to still be there when we clear pending on the ordered extent. However if we happen to abort the transaction and clean it up, there could be no running transaction, and thus we'll trip the "ASSERT(trans)" check. This is obviously incorrect, and the code properly deals with the case that the transaction doesn't exist. Fix this ASSERT() to only fire if there's no trans and we don't have BTRFS_FS_ERROR() set on the file system.
CC: stable@vger.kernel.org # 4.14+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Josef Bacik <josef@toxicpanda.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
show more ...
|
Revision tags: v6.1.46, v6.1.45 |
|
#
84af994b |
| 09-Aug-2023 |
Ruan Jinjie <ruanjinjie@huawei.com> |
btrfs: use LIST_HEAD() to initialize the list_head
Use LIST_HEAD() to initialize the list_head instead of open-coding it.
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com> Reviewed-by: David Sterb
btrfs: use LIST_HEAD() to initialize the list_head
Use LIST_HEAD() to initialize the list_head instead of open-coding it.
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
show more ...
|
Revision tags: v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37 |
|
#
6648cedd |
| 28-Jun-2023 |
Christoph Hellwig <hch@lst.de> |
btrfs: remove btrfs_writepage_endio_finish_ordered
btrfs_writepage_endio_finish_ordered is a small wrapper around btrfs_mark_ordered_io_finished that just changs the argument passing slightly, and a
btrfs: remove btrfs_writepage_endio_finish_ordered
btrfs_writepage_endio_finish_ordered is a small wrapper around btrfs_mark_ordered_io_finished that just changs the argument passing slightly, and adds a tracepoint.
Move the tracpoint to btrfs_mark_ordered_io_finished, which means it now also covers the error handling in btrfs_cleanup_ordered_extent and switch all callers to just call btrfs_mark_ordered_io_finished directly.
Reviewed-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
show more ...
|
Revision tags: v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32 |
|
#
122e9ede |
| 31-May-2023 |
Christoph Hellwig <hch@lst.de> |
btrfs: add a btrfs_finish_ordered_extent helper
Add a helper to complete an ordered_extent without first doing a lookup. The tracepoint cannot use the ordered_extent class as we also want to print t
btrfs: add a btrfs_finish_ordered_extent helper
Add a helper to complete an ordered_extent without first doing a lookup. The tracepoint cannot use the ordered_extent class as we also want to print the range.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
show more ...
|
#
2d6f107e |
| 31-May-2023 |
Christoph Hellwig <hch@lst.de> |
btrfs: factor out a btrfs_queue_ordered_fn helper
Factor out a helper to queue up an ordered_extent completion in a work queue. This new helper will later be used complete an ordered_extent without
btrfs: factor out a btrfs_queue_ordered_fn helper
Factor out a helper to queue up an ordered_extent completion in a work queue. This new helper will later be used complete an ordered_extent without first doing a lookup.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
show more ...
|