[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2d3125e9-0e5c-644f-1ffa-e41ba55b4ecb@kernel.org>
Date: Thu, 13 Apr 2023 17:49:44 +0800
From: Chao Yu <chao@...nel.org>
To: Jaegeuk Kim <jaegeuk@...nel.org>
Cc: linux-kernel@...r.kernel.org,
linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: fix to tag FIEMAP_EXTENT_DELALLOC in
fiemap() for delay allocated extent
On 2023/4/12 1:08, Jaegeuk Kim wrote:
> On 04/11, Chao Yu wrote:
>> 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.
>
> I was thinking fallocate/pin cases to give zero data. But, we may need to check
> the space discarded securely or disk support?
I thought about similar scheme, we can add F2FS_GET_BLOCK_ZERO for fallocate/pin
case to zero data in valid block address, but the problem is how can we distinguish
zero/valid data from valid block address w/o additional unwritten flag of metadata.
e.g.
1. write page [0,511] w/ valid data;
2. fallocate/pin page [512,1023] w/ zero data;
3. fiemap file --- what output should it be?
Thanks,
>
>>
>> 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@...nel.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@...ts.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Powered by blists - more mailing lists