From: Ritesh Harjani <riteshh@linux.ibm.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-ext4@vger.kernel.org, jack@suse.cz, tytso@mit.edu,
adilger.kernel@dilger.ca, linux-fsdevel@vger.kernel.org,
darrick.wong@oracle.com, hch@infradead.org, cmaiolino@redhat.com,
david@fromorbit.com
Subject: Re: [PATCHv5 6/6] Documentation: Correct the description of FIEMAP_EXTENT_LAST
Date: Mon, 2 Mar 2020 13:40:06 +0530 [thread overview]
Message-ID: <20200302081007.8B710A4070@d06av23.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <20200228153650.GG29971@bombadil.infradead.org>
On 2/28/20 9:06 PM, Matthew Wilcox wrote:
> On Fri, Feb 28, 2020 at 02:56:59PM +0530, Ritesh Harjani wrote:
>> Currently FIEMAP_EXTENT_LAST is not working consistently across
>> different filesystem's fiemap implementations. So add more information
>> about how else this flag could set in other implementation.
>>
>> Also in general, user should not completely rely on this flag as
>> such since it could return false value for e.g.
>> when there is a delalloc extent which might get converted during
>> writeback, immediately after the fiemap calls return.
>>
>> Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
>> ---
>> Documentation/filesystems/fiemap.txt | 10 +++++-----
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/filesystems/fiemap.txt b/Documentation/filesystems/fiemap.txt
>> index f6d9c99103a4..fedfa9b9dde5 100644
>> --- a/Documentation/filesystems/fiemap.txt
>> +++ b/Documentation/filesystems/fiemap.txt
>> @@ -71,8 +71,7 @@ allocated is less than would be required to map the requested range,
>> the maximum number of extents that can be mapped in the fm_extent[]
>> array will be returned and fm_mapped_extents will be equal to
>> fm_extent_count. In that case, the last extent in the array will not
>> -complete the requested range and will not have the FIEMAP_EXTENT_LAST
>> -flag set (see the next section on extent flags).
>> +complete the requested range.
>
> This sentence still seems like it should be true. If the filesystem knows
> there are more extents to come, it will definitely not set the LAST flag.
>
sure.
>> @@ -96,7 +95,7 @@ block size of the file system. With the exception of extents flagged as
>> FIEMAP_EXTENT_MERGED, adjacent extents will not be merged.
>>
>> The fe_flags field contains flags which describe the extent returned.
>> -A special flag, FIEMAP_EXTENT_LAST is always set on the last extent in
>> +A special flag, FIEMAP_EXTENT_LAST *may be* set on the last extent in
>> the file so that the process making fiemap calls can determine when no
>> more extents are available, without having to call the ioctl again.
>
> I'm not sure I'd highlight 'may be' here.
Sure.
>
>> @@ -115,8 +114,9 @@ data. Note that the opposite is not true - it would be valid for
>> FIEMAP_EXTENT_NOT_ALIGNED to appear alone.
>>
>> * FIEMAP_EXTENT_LAST
>> -This is the last extent in the file. A mapping attempt past this
>> -extent will return nothing.
>> +This is generally the last extent in the file. A mapping attempt past this
>> +extent may return nothing. In some implementations this flag is also set on
>> +the last dataset queried by the user (via fiemap->fm_length).
>
> The word 'dataset' is used nowhere else in this document. How about
>
> "Some filesystems set this flag to indicate this extent is the last one in
> the range queried by the user"
Sure.
Thanks for the review.
Will make the suggested changes and send a v6.
-ritesh
next prev parent reply other threads:[~2020-03-02 8:10 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-28 9:26 [PATCHv5 0/6] ext4: bmap & fiemap conversion to use iomap Ritesh Harjani
2020-02-28 9:26 ` [PATCHv5 1/6] ext4: Add IOMAP_F_MERGED for non-extent based mapping Ritesh Harjani
2020-02-28 15:26 ` Darrick J. Wong
2020-03-13 19:52 ` Theodore Y. Ts'o
2020-02-28 9:26 ` [PATCHv5 2/6] ext4: Optimize ext4_ext_precache for 0 depth Ritesh Harjani
2020-03-13 20:05 ` Theodore Y. Ts'o
2020-02-28 9:26 ` [PATCHv5 3/6] ext4: Move ext4 bmap to use iomap infrastructure Ritesh Harjani
2020-02-28 15:25 ` Darrick J. Wong
2020-03-02 8:58 ` Ritesh Harjani
2020-03-03 15:47 ` Darrick J. Wong
2020-03-04 12:42 ` Jan Kara
2020-03-04 15:37 ` Darrick J. Wong
2020-03-07 2:32 ` Theodore Y. Ts'o
2020-03-06 17:49 ` Ritesh Harjani
2020-03-07 0:51 ` Darrick J. Wong
2020-03-07 5:50 ` Ritesh Harjani
2020-03-13 20:16 ` Theodore Y. Ts'o
2020-02-28 9:26 ` [PATCHv5 4/6] ext4: Make ext4_ind_map_blocks work with fiemap Ritesh Harjani
2020-03-13 20:18 ` Theodore Y. Ts'o
2020-02-28 9:26 ` [PATCHv5 5/6] ext4: Move ext4_fiemap to use iomap framework Ritesh Harjani
2020-02-28 15:21 ` Darrick J. Wong
2020-03-14 3:03 ` Theodore Y. Ts'o
2020-02-28 9:26 ` [PATCHv5 6/6] Documentation: Correct the description of FIEMAP_EXTENT_LAST Ritesh Harjani
2020-02-28 15:20 ` Darrick J. Wong
2020-02-28 15:36 ` Matthew Wilcox
2020-03-02 8:10 ` Ritesh Harjani [this message]
2020-03-14 3:48 ` Theodore Y. Ts'o
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=20200302081007.8B710A4070@d06av23.portsmouth.uk.ibm.com \
--to=riteshh@linux.ibm.com \
--cc=adilger.kernel@dilger.ca \
--cc=cmaiolino@redhat.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=willy@infradead.org \
/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).