[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <958f5586-c37a-4836-87a2-4530428b0a4e@wdc.com>
Date: Fri, 13 Sep 2024 05:42:38 +0000
From: Johannes Thumshirn <Johannes.Thumshirn@....com>
To: Qu Wenruo <quwenruo.btrfs@....com>, Johannes Thumshirn <jth@...nel.org>,
Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>, David Sterba
<dsterba@...e.com>, "open list:BTRFS FILE SYSTEM"
<linux-btrfs@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>
CC: WenRuo Qu <wqu@...e.com>
Subject: Re: [PATCH] btrfs: scrub: skip PREALLOC extents on RAID stripe-tree
On 12.09.24 23:32, Qu Wenruo wrote:
>
>
> 在 2024/9/13 00:03, Johannes Thumshirn 写道:
>> From: Johannes Thumshirn <johannes.thumshirn@....com>
>>
>> When scrubbing a RAID stripe-tree based filesystem with preallocated
>> extents, the btrfs_map_block() called by
>> scrub_submit_extent_sector_read() will return ENOENT, because there is
>> no RAID stripe-tree entry for preallocated extents. This then causes
>> the sector to be marked as a sector with an I/O error.
>>
>> To prevent this false alert don't mark secotors for that
>> btrfs_map_block() returned an ENOENT as I/O errors but skip them.
>>
>> This results for example in errors in fstests' btrfs/060 .. btrfs/074
>> which all perform fsstress and scrub operations. Whit this fix, these
>> errors are gone and the tests pass again.
>>
>> Cc: Qu Wenru <wqu@...e.com>
>
> My concern is, ENOENT can be some real problems other than PREALLOC.
> I'd prefer this to be the last-resort method.
Hm but what else could create an entry in the extent tree without having
it in the stripe tree? I can't really think of a situation creating this
layout.
> Would it be possible to create an RST entry for preallocated operations
> manually? E.g. without creating a dummy OE, but just insert the needed
> RST entries into RST tree at fallocate time?
Let me give it a try. But I'm a bit less happy to do so, as RST already
increases the write amplification.
Powered by blists - more mailing lists