From: Eric Sandeen <sandeen@sandeen.net>
To: Carlos Maiolino <cmaiolino@redhat.com>, linux-fsdevel@vger.kernel.org
Cc: tytso@mit.edu, david@fromorbit.com, hch@infradead.org
Subject: Re: Ext4 fiemap implementation
Date: Fri, 1 Jun 2018 10:01:54 -0500 [thread overview]
Message-ID: <f63d1a08-1b6a-d2ad-48af-d8b08e1a4e26@sandeen.net> (raw)
In-Reply-To: <20180601123621.avcgzyedbiqxlktf@odin.usersys.redhat.com>
On 6/1/18 7:36 AM, Carlos Maiolino wrote:
> Hi,
>
> I've been working on a patchset to get rid of the ->bmap infrastructure.
>
> FIBMAP ioctl should be supported forever, so, basically I'm using Dave's idea to
> use ->fiemap() implementation to handle FIBMAP ioctl, however, I've been facing
> an issue with Ext4 FIEMAP in this case; basically:
>
> When issuing a FIEMAP ioctl to Ext4with something like this:
>
> fiemap->fm_start = block_num * blocksize;
> fiemap->fm_length = 1;
> fmap->fm_extent_count = 1;
>
> I was expecting the fiemap_extent returned, to contain the physical block
> from the logical request above, so:
>
> physical block == fiemap_ext.fe_physical / blocksize
>
>
> This works on XFS, which is using iomap_fiemap infrastructure. However, it
> doesn't work on Ext4.
>
> Ext4 always returns in fiemap_ext.fe_physical, the start of the extent, and not
> the offset requested initially (if it lies somewhere beyond the first block in
> the extent).
>
> Ted, is there any restriction why ext4_fiemap isn't using iomap_fiemap()? Or any
> reason why ext4 fiemap always returns the offset from the beginning of the
> extent? Would you oppose to have it updated to return the offset initially
> requested? Or maybe, change ext4_fiemap() to use iomap_fiemap()?
>
> I read the fiemap documentation, but I didn't get a clear understanding if
> fiemap should be returning the beginning of the extent, the offset initially
> requested, or if it depends on FS implementation.
I think the fiemap docs[1] explicitly state that ext4's behavior is valid:
> Extents returned mirror
> those on disk - that is, the logical offset of the 1st returned extent
> may start before fm_start, and the range covered by the last returned
> extent may end after fm_length.
so if you're going to use this, you will need to work out //your// block
based on the overlapping extent that gets returned, just like userspace would
do.
-Eric
[1] Documentation/filesystems/fiemap.txt
next prev parent reply other threads:[~2018-06-01 15:01 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-01 12:36 Ext4 fiemap implementation Carlos Maiolino
2018-06-01 15:01 ` Eric Sandeen [this message]
2018-06-03 3:28 ` Theodore Y. Ts'o
2018-06-04 16:43 ` Darrick J. Wong
2018-06-06 13:13 ` Carlos Maiolino
2018-06-06 14:40 ` Darrick J. Wong
2018-06-07 8:31 ` Carlos Maiolino
2018-06-07 16:25 ` Darrick J. Wong
2018-06-08 8:18 ` Carlos Maiolino
2018-06-08 22:41 ` Mark Fasheh
2018-06-11 7:28 ` Carlos Maiolino
2018-06-12 23:52 ` Mark Fasheh
2018-06-13 3:06 ` Theodore Y. Ts'o
2018-06-13 3:32 ` Dave Chinner
2018-06-13 5:04 ` Theodore Y. Ts'o
2018-06-13 7:41 ` Dave Chinner
2018-06-13 12:09 ` Christoph Hellwig
2018-06-14 8:14 ` Carlos Maiolino
2018-06-01 18:57 ` Andreas Dilger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f63d1a08-1b6a-d2ad-48af-d8b08e1a4e26@sandeen.net \
--to=sandeen@sandeen.net \
--cc=cmaiolino@redhat.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).