mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chao Yu <chao@kernel.org>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: fix to tag FIEMAP_EXTENT_DELALLOC in fiemap() for delay allocated extent
Date: Tue, 11 Apr 2023 16:36:12 +0800	[thread overview]
Message-ID: <2341db3b-5a40-a9f0-51f1-29a8908e3e98@kernel.org> (raw)
In-Reply-To: <538fd229-28ae-0ec5-ef07-35d505fbb8a9@kernel.org>

On 2023/4/11 16:14, Chao Yu wrote:
> On 2023/4/11 1:57, Jaegeuk Kim wrote:
>> On 04/08, Chao Yu wrote:
>>> On 2023/4/8 4:59, Jaegeuk Kim wrote:
>>>> This breaks generic/009?
>>>
>>> I guess it is as expected?
>>>
>>> Please check description of fiemap ioctl manual from [1]:
>>>
>>> FIEMAP_EXTENT_UNKNOWN
>>> The location of this extent is currently unknown. This may
>>> indicate the data is stored on an inaccessible volume or that
>>> no storage has been allocated for the file yet.
>>>
>>> FIEMAP_EXTENT_DELALLOC
>>> This will also set FIEMAP_EXTENT_UNKNOWN.
>>>
>>> Delayed allocation - while there is data for this extent, its
>>> physical location has not been allocated yet.
>>>
>>> FIEMAP_EXTENT_UNWRITTEN
>>> Unwritten extent - the extent is allocated but its data has not
>>> been initialized. This indicates the extent’s data will be all
>>> zero if read through the filesystem but the contents are undefined
>>> if read directly from the device.
>>>
>>> [1] https://www.kernel.org/doc/html/latest/filesystems/fiemap.html
>>>
>>> According to its description, f2fs only support
>>> FIEMAP_EXTENT_{UNKNOWN, DELALLOC}, but not support
>>> FIEMAP_EXTENT_UNWRITTEN.
>>
>> No, I don't think so.
> 
> Jaegeuk,
> 
> Could you please check the detailed description of FIEMAP_EXTENT_UNWRITTEN?
> The flag indicates two conditions:
> 1. on-disk blkaddrs were allocated for extent, and the extent is tagged as
> unwritten status.
> 2. data readed on those blocks will be all zero.

Sorry, I mean:

1. on-disk blkaddrs were allocated for extent;
2. extent is tagged as unwritten status, data readed on those blocks will be
all zero.

Thanks,

> 
> So, let's check f2fs' status:
> - fallocate only reserve valid block count and set NEW_ADDR in dnode, so
> it does not match condition 1)
> - pin & fallocate preallocates blkaddrs and set blkaddrs in dnode, but
> content on those blkaddrs may contain zero or random data, so it does not
> match  condition 2)
> 
> Christoph describes this issue in below patch as well, you can check it.
> da8c7fecc9c7 ("f2fs: rename F2FS_MAP_UNWRITTEN to F2FS_MAP_DELALLOC")
> 
> Am I missing something?
> 
> Thanks,
> 
>>
>>>
>>> So 009, 092, 094 .. which expects unwritten status from extent will
>>> fail.
>>>
>>> How about disabling those testcase?
>>>
>>> Thanks,
>>>
>>>>
>>>> On 04/05, Chao Yu wrote:
>>>>> xfstest generic/614 fails to run due below reason:
>>>>>
>>>>> generic/614 1s ... [not run] test requires delayed allocation buffered writes
>>>>>
>>>>> The root cause is f2fs tags wrong fiemap flag for delay allocated
>>>>> extent.
>>>>>
>>>>> Quoted from fiemap.h:
>>>>> FIEMAP_EXTENT_UNKNOWN        0x00000002 /* Data location unknown. */
>>>>> FIEMAP_EXTENT_DELALLOC        0x00000004 /* Location still pending.
>>>>>                             * Sets EXTENT_UNKNOWN. */
>>>>> FIEMAP_EXTENT_UNWRITTEN        0x00000800 /* Space allocated, but
>>>>>                             * no data (i.e. zero). */
>>>>>
>>>>> FIEMAP_EXTENT_UNWRITTEN means block address is preallocated, but w/o
>>>>> been written any data, which status f2fs is not supported now, for all
>>>>> NEW_ADDR block addresses, it means delay allocated blocks, so let's
>>>>> tag FIEMAP_EXTENT_DELALLOC instead.
>>>>>
>>>>> Testcase:
>>>>> xfs_io -f -c 'pwrite 0 64k' /mnt/f2fs/file;
>>>>> filefrag -v /mnt/f2fs/file
>>>>>
>>>>> Output:
>>>>> - Before
>>>>> Filesystem type is: f2f52010
>>>>> Fize of /mnt/f2fs/file is 65536 (16 blocks of 4096 bytes)
>>>>>    ext:     logical_offset:        physical_offset: length:   expected: flags:
>>>>>      0:        0..      15:          0..        15:     16:             last,unwritten,merged,eof
>>>>> /mnt/f2fs/file: 1 extent found
>>>>>
>>>>> After:
>>>>> Filesystem type is: f2f52010
>>>>> File size of /mnt/f2fs/file is 65536 (16 blocks of 4096 bytes)
>>>>>    ext:     logical_offset:        physical_offset: length:   expected: flags:
>>>>>      0:        0..      15:          0..         0:      0:             last,unknown_loc,delalloc,eof
>>>>> /mnt/f2fs/file: 1 extent found
>>>>>
>>>>> Fixes: 7f63eb77af7b ("f2fs: report unwritten area in f2fs_fiemap")
>>>>> Signed-off-by: Chao Yu <chao@kernel.org>
>>>>> ---
>>>>>    fs/f2fs/data.c | 7 +++++--
>>>>>    1 file changed, 5 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
>>>>> index 359de650772e..3afc9764743e 100644
>>>>> --- a/fs/f2fs/data.c
>>>>> +++ b/fs/f2fs/data.c
>>>>> @@ -1995,7 +1995,10 @@ int f2fs_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
>>>>>        }
>>>>>        if (size) {
>>>>> -        flags |= FIEMAP_EXTENT_MERGED;
>>>>> +        if (flags & FIEMAP_EXTENT_DELALLOC)
>>>>> +            phys = 0;
>>>>> +        else
>>>>> +            flags |= FIEMAP_EXTENT_MERGED;
>>>>>            if (IS_ENCRYPTED(inode))
>>>>>                flags |= FIEMAP_EXTENT_DATA_ENCRYPTED;
>>>>> @@ -2035,7 +2038,7 @@ int f2fs_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
>>>>>                    size += blks_to_bytes(inode, 1);
>>>>>                }
>>>>>            } else if (map.m_flags & F2FS_MAP_DELALLOC) {
>>>>> -            flags = FIEMAP_EXTENT_UNWRITTEN;
>>>>> +            flags = FIEMAP_EXTENT_DELALLOC;
>>>>>            }
>>>>>            start_blk += bytes_to_blks(inode, size);
>>>>> -- 
>>>>> 2.36.1
> 
> 
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply	other threads:[~2023-04-11  8:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-05 14:43 Chao Yu
2023-04-07 20:59 ` Jaegeuk Kim
2023-04-08  2:57   ` Chao Yu
2023-04-10 17:57     ` Jaegeuk Kim
2023-04-11  8:14       ` Chao Yu
2023-04-11  8:36         ` Chao Yu [this message]
2023-04-11 17:08           ` [f2fs-dev] " Jaegeuk Kim
2023-04-13  9:49             ` Chao Yu
2023-04-19 15:30               ` Chao Yu

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=2341db3b-5a40-a9f0-51f1-29a8908e3e98@kernel.org \
    --to=chao@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.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

all inboxes | Powered by JetHome®