linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).