From: Nikolay Borisov <nborisov@suse.com>
To: Eric Sandeen <sandeen@sandeen.net>, linux-xfs@vger.kernel.org
Cc: fstests@vger.kernel.org, eguan@redhat.com, david@fromorbit.com,
darrick.wong@oracle.com
Subject: Re: [PATCH v4 2/2] fiemap: Implement ranged query
Date: Fri, 17 Nov 2017 11:39:02 +0200 [thread overview]
Message-ID: <ee205fde-0c42-5ed4-8bce-ad5d0841a60a@suse.com> (raw)
In-Reply-To: <26736c47-b807-62eb-202b-4a959f16832c@sandeen.net>
On 17.11.2017 04:47, Eric Sandeen wrote:
> On 11/15/17 6:10 AM, Nikolay Borisov wrote:
>> Currently the fiemap implementation of xfs_io doesn't support making ranged
>> queries. This patch implements two optional arguments which take the starting
>> offset and the length of the region to be queried. This also requires changing
>> of the final hole range is calculated. Namely, it's now being done as
>> [last_logical, logical addres of next extent] rather than being statically
>> determined by [last_logical, filesize].
>>
>> Signed-off-by: Nikolay Borisov <nborisov@suse.com>
>
> Ok, so first an apology for taking so long to really, really look at this.
>
> When I started reviewing this, and dreading the complexity of the fiemap loop
> control (why /is/ it so complicated today, anyway?) I started wondering: why
> do we need a lot more logic? Why can't we simply:
>
> 1) Set a non-zero mapping start
> 2) Set a non-maximal mapping length
> 3) Decrement that length as we map, and
> 4) When the kernel tells us mapped_extents for the range is 0, stop.
>
> And this is what I ended up with, which seems a lot simpler. Is there any
> problem with this approach?
>
> This /almost/ passes your test; what it doesn't do is show holes at the edges
> of the mapping range, but I think that's ok.
>
> The interface itself says nothing about holes, it only maps allocated ranges.
>
> If we ask for a ranged query, I think it's appropriate to /not/ print holes
> on either side of the requested range.
>
>
> Thoughts?
I definitely like the simplicity and am happy for this to replace my
patches. But with this do we require the fixup for existing hole tests
(I don't think so)?
>
>
>
> diff --git a/io/fiemap.c b/io/fiemap.c
> index bdcfacd..bbf6d63 100644
> --- a/io/fiemap.c
> +++ b/io/fiemap.c
> @@ -49,6 +49,8 @@ fiemap_help(void)
> " -l -- also displays the length of each extent in 512-byte blocks.\n"
> " -n -- query n extents.\n"
> " -v -- Verbose information\n"
> +" offset is the starting offset to map, and is optional. If offset is\n"
> +" specified, mapping length may (optionally) be specified as well."
> "\n"));
> }
>
> @@ -235,9 +237,15 @@ fiemap_f(
> int boff_w = 16;
> int tot_w = 5; /* 5 since its just one number */
> int flg_w = 5;
> - __u64 last_logical = 0;
> + __u64 last_logical = 0; /* last extent offset handled */
> + off64_t start_offset = 0; /* mapping start */
> + off64_t length = -1LL; /* mapping length */
> + off64_t range_end = -1LL; /* mapping end*/
> + size_t fsblocksize, fssectsize;
> struct stat st;
>
> + init_cvtnum(&fsblocksize, &fssectsize);
> +
> while ((c = getopt(argc, argv, "aln:v")) != EOF) {
> switch (c) {
> case 'a':
> @@ -257,6 +265,27 @@ fiemap_f(
> }
> }
>
> + /* Range start (optional) */
> + if (optind < argc) {
> + start_offset = cvtnum(fsblocksize, fssectsize, argv[optind]);
> + if (start_offset < 0) {
> + printf("non-numeric offset argument -- %s\n", argv[optind]);
> + return 0;
> + }
> + last_logical = start_offset;
> + optind++;
> + }
> +
> + /* Range length (optional if range start was specified) */
> + if (optind < argc) {
> + length = cvtnum(fsblocksize, fssectsize, argv[optind]);
> + if (length < 0) {
> + printf("non-numeric len argument -- %s\n", argv[optind]);
> + return 0;
> + }
> + range_end = start_offset + length;
> + }
> +
> map_size = sizeof(struct fiemap) +
> (EXTENT_BATCH * sizeof(struct fiemap_extent));
> fiemap = malloc(map_size);
> @@ -274,7 +303,7 @@ fiemap_f(
> memset(fiemap, 0, map_size);
> fiemap->fm_flags = fiemap_flags;
> fiemap->fm_start = last_logical;
> - fiemap->fm_length = -1LL;
> + fiemap->fm_length = range_end - last_logical;
> fiemap->fm_extent_count = EXTENT_BATCH;
>
> ret = ioctl(file->fd, FS_IOC_FIEMAP, (unsigned long)fiemap);
> @@ -336,7 +365,8 @@ fiemap_f(
> return 0;
> }
>
> - if (cur_extent && last_logical < st.st_size)
> + /* Print last hole to EOF only if range end was not specified */
> + if (cur_extent && (range_end == -1LL) && (last_logical < st.st_size))
> print_hole(foff_w, boff_w, tot_w, cur_extent, lflag, !vflag,
> BTOBBT(last_logical), BTOBBT(st.st_size));
>
> @@ -353,7 +383,7 @@ fiemap_init(void)
> fiemap_cmd.argmin = 0;
> fiemap_cmd.argmax = -1;
> fiemap_cmd.flags = CMD_NOMAP_OK | CMD_FOREIGN_OK;
> - fiemap_cmd.args = _("[-alv] [-n nx]");
> + fiemap_cmd.args = _("[-alv] [-n nx] [offset [len]]");
> fiemap_cmd.oneline = _("print block mapping for a file");
> fiemap_cmd.help = fiemap_help;
>
>
>
next prev parent reply other threads:[~2017-11-17 9:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-15 12:10 [PATCH v4 1/2] fiemap: Factor out actual fiemap call code Nikolay Borisov
2017-11-15 12:10 ` [PATCH v4 2/2] fiemap: Implement ranged query Nikolay Borisov
2017-11-17 2:47 ` Eric Sandeen
2017-11-17 9:39 ` Nikolay Borisov [this message]
2017-11-15 12:11 ` [PATCH v4 1/3] generic: Adjust generic test outputs for new fiemap imeplementation Nikolay Borisov
2017-11-15 12:11 ` [PATCH v4 2/3] common: Implement fiemap's range query check Nikolay Borisov
2017-11-21 5:39 ` Eryu Guan
2017-11-15 12:11 ` [PATCH v4 3/3] xfs: initial fiemap range query test Nikolay Borisov
2017-11-21 5:45 ` Eryu Guan
2017-11-21 15:10 ` Nikolay Borisov
2017-11-21 5:29 ` [PATCH v4 1/3] generic: Adjust generic test outputs for new fiemap imeplementation Eryu Guan
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=ee205fde-0c42-5ed4-8bce-ad5d0841a60a@suse.com \
--to=nborisov@suse.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=eguan@redhat.com \
--cc=fstests@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@sandeen.net \
/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).