mbox series

[RFC,0/2] ext4: bmap & fiemap conversion to use iomap

Message ID 20190820130634.25954-1-riteshh@linux.ibm.com
Headers show
Series ext4: bmap & fiemap conversion to use iomap | expand

Message

Ritesh Harjani Aug. 20, 2019, 1:06 p.m. UTC 
Hello,

These are RFC patches to get community view on converting
ext4 bmap & fiemap to iomap infrastructure. This reduces the users
of ext4_get_block API and thus a step towards getting rid of
buffer_heads from ext4. Also reduces the line of code by making
use of iomap infrastructure (ex4_iomap_begin) which is already
used for other operations.

This gets rid of special implementation of ext4_fill_fiemap_extents
& ext4_find_delayed_extent and thus only relies upon ext4_map_blocks
& iomap_fiemap (ext4_iomap_begin) for mapping. It looked more logical
thing to do, but I appreciate if anyone has any review/feedback
comments about this part.

Didn't get any regression on some basic xfstests in tests/ext4/
with mkfs option of "-b 4096". Please let me know if I should also test
any special configurations?

Patches can be cleanly applied over Linux 5.3-rc5.


Ritesh Harjani (2):
  ext4: Move ext4 bmap to use iomap infrastructure.
  ext4: Move ext4_fiemap to iomap infrastructure

 fs/ext4/extents.c | 294 +++++++---------------------------------------
 fs/ext4/inline.c  |  41 -------
 fs/ext4/inode.c   |  17 ++-
 3 files changed, 53 insertions(+), 299 deletions(-)

Comments

Ritesh Harjani Aug. 27, 2019, 3:58 a.m. UTC | #1 
Hello Ted/Jan/Andreas,

Any review comments on this please?


One more thing which I wanted to discuss about this patch set is 
testcase generic/473 ("Hole + Data" case).
With iomap we only report extent information upto what user requested
which I think is different than previous implementation.

I see that with iomap, generic/473 test case("hole + data" case) shows 
as failed, although it reported the data extents only upto what user 
requested. Also as per Documentation/filesystems/fiemap.txt, both
outputs are proper.


i.e. for below case (generic/473)
  63 echo "Hole + Data"
  64 $XFS_IO_PROG -c "fiemap -v 0 65k" $file | _filter_fiemap

<output for both ext4(with this patchset) & XFS is this>

generic/473 3s ... - output mismatch (see 
/home/qemu/work/xfstests-dev/results//xfs_filesystem/generic/473.out.bad)
     --- tests/generic/473.out   2019-07-05 10:49:42.130902595 +0530
     +++ 
/home/qemu/work/xfstests-dev/results//xfs_filesystem/generic/473.out.bad 
        2019-08-27 09:26:20.823980693 +0530
     @@ -6,7 +6,7 @@
      1: [256..287]: hole
      Hole + Data
      0: [0..127]: hole
     -1: [128..255]: data
     +1: [128..135]: data
      Hole + Data + Hole
      0: [0..127]: hole
     ...


-ritesh

On 8/20/19 6:36 PM, Ritesh Harjani wrote:
> Hello,
> 
> These are RFC patches to get community view on converting
> ext4 bmap & fiemap to iomap infrastructure. This reduces the users
> of ext4_get_block API and thus a step towards getting rid of
> buffer_heads from ext4. Also reduces the line of code by making
> use of iomap infrastructure (ex4_iomap_begin) which is already
> used for other operations.
> 
> This gets rid of special implementation of ext4_fill_fiemap_extents
> & ext4_find_delayed_extent and thus only relies upon ext4_map_blocks
> & iomap_fiemap (ext4_iomap_begin) for mapping. It looked more logical
> thing to do, but I appreciate if anyone has any review/feedback
> comments about this part.
> 
> Didn't get any regression on some basic xfstests in tests/ext4/
> with mkfs option of "-b 4096". Please let me know if I should also test
> any special configurations?
> 
> Patches can be cleanly applied over Linux 5.3-rc5.
> 
> 
> Ritesh Harjani (2):
>    ext4: Move ext4 bmap to use iomap infrastructure.
>    ext4: Move ext4_fiemap to iomap infrastructure
> 
>   fs/ext4/extents.c | 294 +++++++---------------------------------------
>   fs/ext4/inline.c  |  41 -------
>   fs/ext4/inode.c   |  17 ++-
>   3 files changed, 53 insertions(+), 299 deletions(-)
>