lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ