We have an btrfs filesystem which have crashed and fails to mount. The
filesystem is on an extrenal SSD and it is quite possible it got
disconnected badly or had an unclean shutdown due to suspend issues.
[ 447.321770] BTRFS critical (device sdc3): corrupt leaf: root=256
block=2036170752 slot=1 i
tree checker then the image will
be rejected to be mounted.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208929
Signed-off-by: Su Yue
---
fs/btrfs/tree-checker.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/fs/btrfs/tree-checker.c b/fs/btrfs/tree-checker.c
index
On Sun, Jan 03, 2021 at 05:28:04PM +0800, Su Yue wrote:
> while mounting the poc image user-provided, kernel panics due to the
> invalid chunk item whose end is less than start.
>
> [ 66.387422] loop: module loaded
> [ 66.
ogical start 37748736
and length
18446744073701163008. The calculated end 29360127 is overflowed
obviously.
-EEXIST was caught by insert_state() because of the duplicate
end and
extent_io_tree_panic() was called.
Add overflow check of chunk item end in tree checker then the
image will
be reject
obviously.
-EEXIST was caught by insert_state() because of the duplicate end and
extent_io_tree_panic() was called.
Add overflow check of chunk item end in tree checker then the image will
be rejected to be mounted.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208929
Signed-off-by: Su Yue
te() because of the duplicate end and
extent_io_tree_panic() was called.
Add overflow check of chunk item end in tree checker then the image will
be rejected to be mounted.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208929
Signed-off-by: Su Yue
---
fs/btrfs/tree-checker.c | 7
valid S_IF* bit(s)
Tree-checker detects an invalid inode mode bit.
From previous report, it should be caused by older kernel around 2014.
> [26876.491171] BTRFS error (device dm-0): block=739531833344 read time
> tree block corruption detected
>
> It is triggered whenever stat() i
:
Input/output error
ls: cannot access './/2018-05-31.201834+1000AEST.html':
Input/output error
ls: cannot access './/2018-05-31.222947+1000AEST.html':
Input/output error
https://btrfs.wiki.kernel.org/index.php/Tree-checker#How_to_handle_such_error
tells me to post on this mailing li
On Fri, Oct 04, 2019 at 05:31:30PM +0800, Qu Wenruo wrote:
> There is a false alerts of tree-checker when running fstests/btrfs/063
> in a loop.
>
> The bug is caused by commit 59b0d030fb30 ("btrfs: tree-checker: Try to detect
> missing INODE_ITEM").
> For the full err
On Fri, Oct 04, 2019 at 03:15:51PM +0100, Filipe Manana wrote:
> On Fri, Oct 4, 2019 at 11:27 AM Qu Wenruo wrote:
> > Reported-by: David Sterba
> > Fixes: 59b0d030fb30 ("btrfs: tree-checker: Try to detect missing
> > INODE_ITEM")
>
> So this is bogus, si
On 4.10.19 г. 17:13 ч., Filipe Manana wrote:
> On Fri, Oct 4, 2019 at 2:54 PM Nikolay Borisov wrote:
>>
>>
>>
>> On 4.10.19 г. 12:31 ч., Qu Wenruo wrote:
>>> [BUG]
>>> When running btrfs/063 in a loop, we got the following random write time
>
On Fri, Oct 4, 2019 at 11:27 AM Qu Wenruo wrote:
>
> [BUG]
> When running btrfs/063 in a loop, we got the following random write time
> tree checker error:
>
> BTRFS critical (device dm-4): corrupt leaf: root=18446744073709551610
> block=33095680 slot=2 ino=307 file_offse
On Fri, Oct 4, 2019 at 2:54 PM Nikolay Borisov wrote:
>
>
>
> On 4.10.19 г. 12:31 ч., Qu Wenruo wrote:
> > [BUG]
> > When running btrfs/063 in a loop, we got the following random write time
> > tree checker error:
> >
> > BTRFS critical (device dm-4
On 4.10.19 г. 12:31 ч., Qu Wenruo wrote:
> [BUG]
> When running btrfs/063 in a loop, we got the following random write time
> tree checker error:
>
> BTRFS critical (device dm-4): corrupt leaf: root=18446744073709551610
> block=33095680 slot=2 ino=307 file_offset=0, in
[BUG]
When running btrfs/063 in a loop, we got the following random write time
tree checker error:
BTRFS critical (device dm-4): corrupt leaf: root=18446744073709551610
block=33095680 slot=2 ino=307 file_offset=0, invalid previous key objectid,
have 305 expect 307
BTRFS info (device dm-4
Unlike read time tree checker error, write time error can't be inspected
by "btrfs ins dump-tree", so we need extra info to determine what's
going wrong.
The patch will add the following output for write time tree checker
error:
- The content of the offending tree block
To
Refactor the check for prev_key->objectid of the following key types
into one function, check_prev_ino():
- EXTENT_DATA
- INODE_REF
- DIR_INDEX
- DIR_ITEM
- XATTR_ITEM
Despite the refactor, also add the check of prev_key for INODE_REF.
Signed-off-by: Qu Wenruo
---
fs/btrfs/tree-checker.c | 113
There is a false alerts of tree-checker when running fstests/btrfs/063
in a loop.
The bug is caused by commit 59b0d030fb30 ("btrfs: tree-checker: Try to detect
missing INODE_ITEM").
For the full error analyse, please check the first patch.
The first patch will give it a quick fix, so t
Ok, I'll check it out.
I think I'v tracked down all the files with bad "atime" and cleared
all the BTRFS errors by cp -r , deleting the originals and moving the
copies in .
thanks a bunch .
Charles Wright
On Tue, Sep 24, 2019 at 12:08 AM Chris Murphy wrote:
>
> On Mon, Sep 23, 2019 at 6:35 PM
On Mon, Sep 23, 2019 at 6:35 PM Charles Wright
wrote:
>
> if I boot the 5.0.0-30 kernel and enter the "dwhelper" directory and
> do "dmesg" their is this
>
> [ 199.522886] ata2.00: exception Emask 0x10 SAct 0x8000 SErr 0x2d0100
> action 0x6 frozen
> [ 199.522891] ata2.00: irq_stat 0x0800, in
xpected range is [0, 80501], but you have a super large generation
number.
Doesn't that 18446744073709551492 looks strange? It's
0xff84, by somehow we overflow the generation number.
And tree-checker is doing its job, although not every user likes what
tree-checker is doing
ernel Version: 5.0.0-30-generic
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-4910MQ CPU @ 2.90GHz
Memory: 15.6 GiB of RAM
the web page https://btrfs.wiki.kernel.org/index.php/Tree-checker
asked to report an error like this hear , so her I am :)
any more info or tests you want me to run or pro
On Mon, Aug 26, 2019 at 03:40:39PM +0800, Qu Wenruo wrote:
> For INODE_REF we will check:
> - Objectid (ino) against previous key
> To detect missing INODE_ITEM.
>
> - No overflow/padding in the data payload
> Much like DIR_ITEM, but with less members to check.
>
> Signed-off-by: Qu Wenruo
>
On Mon, Aug 26, 2019 at 07:50:03PM +0800, Qu Wenruo wrote:
>
>
> On 2019/8/26 下午7:45, Nikolay Borisov wrote:
> >
> >
> > On 26.08.19 г. 10:40 ч., Qu Wenruo wrote:
> >> For INODE_REF we will check:
> >> - Objectid (ino) against previous key
> >> To detect missing INODE_ITEM.
> >>
> >> - No overf
From: Qu Wenruo
[ Upstream commit 259ee7754b6793af8bdd77f9ca818bc41cfe9541 ]
This patch will introduce ROOT_ITEM check, which includes:
- Key->objectid and key->offset check
Currently only some easy check, e.g. 0 as rootid is invalid.
- Item size check
Root item size is fixed.
- Generation
From: Qu Wenruo
[ Upstream commit 259ee7754b6793af8bdd77f9ca818bc41cfe9541 ]
This patch will introduce ROOT_ITEM check, which includes:
- Key->objectid and key->offset check
Currently only some easy check, e.g. 0 as rootid is invalid.
- Item size check
Root item size is fixed.
- Generation
On 10/9/19 5:12 PM, WenRuo Qu wrote:
On 2019/9/10 下午5:07, Anand Jain wrote:
diff --git a/fs/btrfs/tree-checker.c b/fs/btrfs/tree-checker.c
index ccd5706199d7..15d1aa7cef1f 100644
--- a/fs/btrfs/tree-checker.c
+++ b/fs/btrfs/tree-checker.c
@@ -686,9 +686,7 @@ static void dev_item_err(const
On 2019/9/10 下午5:07, Anand Jain wrote:
>
>
>
>
>> diff --git a/fs/btrfs/tree-checker.c b/fs/btrfs/tree-checker.c
>> index ccd5706199d7..15d1aa7cef1f 100644
>> --- a/fs/btrfs/tree-checker.c
>> +++ b/fs/btrfs/tree-checker.c
>> @@ -686,9 +686,7 @@ static void dev_item_err(const struct
>> extent_
diff --git a/fs/btrfs/tree-checker.c b/fs/btrfs/tree-checker.c
index ccd5706199d7..15d1aa7cef1f 100644
--- a/fs/btrfs/tree-checker.c
+++ b/fs/btrfs/tree-checker.c
@@ -686,9 +686,7 @@ static void dev_item_err(const struct extent_buffer *eb,
int slot,
static int check_dev_item(struct extent
In check_extent_data_item(), we read file extent type without verifying
if the item size is valid.
Add such check to ensure the file extent type we read is correct.
The check is not as accurate as we need to cover both inline and regular
extents, so it only checks if the item size is larger or eq
t;> dev2=$dev_tmp
>> done
>
> Instead of putting the script here, can't it be turned into a fstest to
> ensure we don't regress in the future?
Sure, already crafting.
Thanks,
Qu
>
>>
>> [CAUSE]
>> Tree-checker uses BTRFS_MAX_DEVS() and
rfs dev add -f $dev2 $mnt || _fail
> btrfs dev del $dev1 $mnt || _fail
> dev_tmp=$dev1
> dev1=$dev2
> dev2=$dev_tmp
> done
Instead of putting the script here, can't it be turned into a fstest to
ensure we don't regress in the future?
>
&
t $dev1 $mnt
_fail()
{
echo "!!! FAILED !!!"
exit 1
}
for ((i = 0; i < 4096; i++)); do
btrfs dev add -f $dev2 $mnt || _fail
btrfs dev del $dev1 $mnt || _fail
dev_tmp=$dev1
dev1=$dev2
dev2=$dev_tmp
done
[CAUSE]
Tree
On 2019/8/28 上午7:26, Anand Jain wrote:
> On 27/8/19 10:05 PM, Qu Wenruo wrote:
>> Btrfs doesn't reuse devid, thus if we add and delete device in a loop,
>> we can increase devid to higher value, triggering tree checker to give a
>> false alert.
>>
>> Furthe
On 27/8/19 10:05 PM, Qu Wenruo wrote:
Btrfs doesn't reuse devid, thus if we add and delete device in a loop,
we can increase devid to higher value, triggering tree checker to give a
false alert.
Furthermore, we have dev extent verification already (after
tree-checker, at mount time).
So ev
Btrfs doesn't reuse devid, thus if we add and delete device in a loop,
we can increase devid to higher value, triggering tree checker to give a
false alert.
Furthermore, we have dev extent verification already (after
tree-checker, at mount time).
So even if user had bitflip on some dev item
On 8/27/19 9:56 AM, Qu Wenruo wrote:
>
>
> On 2019/8/27 下午9:37, Jeff Mahoney wrote:
>> On 8/27/19 9:22 AM, Qu Wenruo wrote:
>>> Btrfs doesn't reuse devid, thus if we add and delete device in a loop,
>>> we can increase devid to higher value, triggering
On 2019/8/27 下午9:37, Jeff Mahoney wrote:
> On 8/27/19 9:22 AM, Qu Wenruo wrote:
>> Btrfs doesn't reuse devid, thus if we add and delete device in a loop,
>> we can increase devid to higher value, triggering tree checker to give a
>> false alert.
>>
>> But we
On 8/27/19 9:22 AM, Qu Wenruo wrote:
> Btrfs doesn't reuse devid, thus if we add and delete device in a loop,
> we can increase devid to higher value, triggering tree checker to give a
> false alert.
>
> But we still don't want to give up the devid check, so here we
Btrfs doesn't reuse devid, thus if we add and delete device in a loop,
we can increase devid to higher value, triggering tree checker to give a
false alert.
But we still don't want to give up the devid check, so here we
compromise by setting a larger devid upper limit, 1<<32.
[BUG]
With crafted image, btrfs will panic at btree operations:
kernel BUG at fs/btrfs/ctree.c:3894!
invalid opcode: [#1] SMP PTI
CPU: 0 PID: 1138 Comm: btrfs-transacti Not tainted 5.0.0-rc8+ #9
RIP: 0010:__push_leaf_left+0x6b6/0x6e0
Code: 00 00 48 98 48 8d 04 80 48 8d 74 80 65 e8 42
On 2019/8/26 下午7:45, Nikolay Borisov wrote:
>
>
> On 26.08.19 г. 10:40 ч., Qu Wenruo wrote:
>> For INODE_REF we will check:
>> - Objectid (ino) against previous key
>> To detect missing INODE_ITEM.
>>
>> - No overflow/padding in the data payload
>> Much like DIR_ITEM, but with less members t
On 26.08.19 г. 10:40 ч., Qu Wenruo wrote:
> For the following items, key->objectid is inode number:
> - DIR_ITEM
> - DIR_INDEX
> - XATTR_ITEM
> - EXTENT_DATA
> - INODE_REF
>
> So in btrfs btree, such items must have its previous item shares the
> same objectid, e.g.:
> (257 INODE_ITEM 0)
> (2
On 26.08.19 г. 10:40 ч., Qu Wenruo wrote:
> For INODE_REF we will check:
> - Objectid (ino) against previous key
> To detect missing INODE_ITEM.
>
> - No overflow/padding in the data payload
> Much like DIR_ITEM, but with less members to check.
>
> Signed-off-by: Qu Wenruo
> ---
> fs/btr
an cover the INODE_ITEM missing case in tree-checker without
much cost, but achieve the check which is normally done by btrfs-check.
(I'm already a little concerned about the fact that kernel tree-checker
is getting stronger and stronger while btrfs-progs can't fix all
problems)
Of co
For the following items, key->objectid is inode number:
- DIR_ITEM
- DIR_INDEX
- XATTR_ITEM
- EXTENT_DATA
- INODE_REF
So in btrfs btree, such items must have its previous item shares the
same objectid, e.g.:
(257 INODE_ITEM 0)
(257 DIR_INDEX xxx)
(257 DIR_ITEM xxx)
(258 INODE_ITEM 0)
(258 INO
For INODE_REF we will check:
- Objectid (ino) against previous key
To detect missing INODE_ITEM.
- No overflow/padding in the data payload
Much like DIR_ITEM, but with less members to check.
Signed-off-by: Qu Wenruo
---
fs/btrfs/tree-checker.c | 53 +
On Fri, Aug 09, 2019 at 09:24:21AM +0800, Qu Wenruo wrote:
> Finally, we are going to add tree-checker support for extent items,
> which includes:
> - EXTENT_ITEM/METADATA_ITEM
> Which futher contains inline backrefs of:
> * TREE_BLOCK_REF
> * SHARED_BLOCK_REF
>
On Fri, Aug 09, 2019 at 09:24:23AM +0800, Qu Wenruo wrote:
> For TREE_BLOCK_REF, SHARED_DATA_REF and SHARED_BLOCK_REF we need to
> check:
> | TREE_BLOCK_REF | SHARED_BLOCK_REF | SHARED_BLOCK_REF
> --++-+--
> key->objectid |
On Fri, Aug 09, 2019 at 09:24:22AM +0800, Qu Wenruo wrote:
> +static int check_extent_item(struct extent_buffer *leaf,
> + struct btrfs_key *key, int slot)
> +{
> + struct btrfs_fs_info *fs_info = leaf->fs_info;
> + struct btrfs_extent_item *ei;
> + bool is_tree
On Thu, Aug 08, 2019 at 11:55:37PM +, WenRuo Qu wrote:
>
>
> On 2019/8/8 下午10:54, David Sterba wrote:
> > On Wed, Aug 07, 2019 at 10:08:41PM +0800, Qu Wenruo wrote:
> >> +
> >> +static int check_extent_item(struct extent_buffer *leaf,
> >> + struct btrfs_key *key, int sl
Finally, we are going to add tree-checker support for extent items,
which includes:
- EXTENT_ITEM/METADATA_ITEM
Which futher contains inline backrefs of:
* TREE_BLOCK_REF
* SHARED_BLOCK_REF
* EXETNT_DATA_REF
* SHARED_DATA_REF
- TREE_BLOCK_REF
- SHARED_BLOCK_REF
- EXTENT_DATA_REF
For TREE_BLOCK_REF, SHARED_DATA_REF and SHARED_BLOCK_REF we need to
check:
| TREE_BLOCK_REF | SHARED_BLOCK_REF | SHARED_BLOCK_REF
--++-+--
key->objectid |Alignment | Alignment|Alignment
key->offset |An
EXTENT_DATA_REF is a little like DIR_ITEM which contains hash in its
key->offset.
This patch will check the following contents:
- Key->objectid
Basic alignment check.
- Hash
Hash of each extent_data_ref item must match key->offset.
- Offset
Basic alignment check.
Signed-off-by: Qu Wenruo
This patch introduces the ability to check extent items.
This check involves:
- key->objectid check
Basic alignment check.
- key->type check
Against btrfs_extent_item::type and SKINNY_METADATA feature.
- key->offset alignment check for EXTENT_ITEM
- key->offset check for METADATA_ITEM
- it
On 2019/8/8 下午10:54, David Sterba wrote:
> On Wed, Aug 07, 2019 at 10:08:41PM +0800, Qu Wenruo wrote:
>> +
>> +static int check_extent_item(struct extent_buffer *leaf,
>> + struct btrfs_key *key, int slot)
>> +{
>> +struct btrfs_fs_info *fs_info = leaf->fs_info;
>> +
On Wed, Aug 07, 2019 at 10:08:43PM +0800, Qu Wenruo wrote:
> EXTENT_DATA_REF is a little like DIR_ITEM which contains hash in its
> key->offset.
>
> This patch will check the following contents:
> - Key->objectid
> Basic alignment check.
>
> - Hash
> Hash of each extent_data_ref item must mat
On Wed, Aug 07, 2019 at 10:08:41PM +0800, Qu Wenruo wrote:
> +
> +static int check_extent_item(struct extent_buffer *leaf,
> + struct btrfs_key *key, int slot)
> +{
> + struct btrfs_fs_info *fs_info = leaf->fs_info;
> + struct btrfs_extent_item *ei;
> + bool is_
For TREE_BLOCK_REF, SHARED_DATA_REF and SHARED_BLOCK_REF we need to
check:
| TREE_BLOCK_REF | SHARED_BLOCK_REF | SHARED_BLOCK_REF
--++-+--
key->objectid |Alignment | Alignment|Alignment
key->offset |An
EXTENT_DATA_REF is a little like DIR_ITEM which contains hash in its
key->offset.
This patch will check the following contents:
- Key->objectid
Basic alignment check.
- Hash
Hash of each extent_data_ref item must match key->offset.
- Offset
Basic alignment check.
Signed-off-by: Qu Wenruo
This patch introduces the ability to check extent items.
This check involves:
- key->objectid check
Basic alignment check.
- key->type check
Against btrfs_extent_item::type and SKINNY_METADATA feature.
- key->offset alignment check for EXTENT_ITEM
- key->offset check for METADATA_ITEM
- it
Finally, we are going to add tree-checker support for extent items,
which includes:
- EXTENT_ITEM/METADATA_ITEM
Which futher contains inline backrefs of:
* TREE_BLOCK_REF
* SHARED_BLOCK_REF
* EXETNT_DATA_REF
* SHARED_DATA_REF
- TREE_BLOCK_REF
- SHARED_BLOCK_REF
- EXTENT_DATA_REF
f (btrfs_root_generation_v2(&ri) >
> >> + btrfs_super_generation(fs_info->super_copy) + 1) {
> >> + generic_err(leaf, slot,
> >> + "invalid root v2 generaetion, have %llu expect (0, %llu]",
> >
> > So (0, %llu] here
On 2019/7/29 下午9:42, Nikolay Borisov wrote:
[...]
>> +
>> +/* key->offset is tree level for METADATA_ITEM_KEY */
>> +if (key->type == BTRFS_METADATA_ITEM_KEY) {
>> +if (key->offset >= BTRFS_MAX_LEVEL) {
>
> make it a compound statement:
>
> if key->type && key->offset. The ex
On 29.07.19 г. 10:43 ч., Qu Wenruo wrote:
> This patch introduces the ability to check extent items.
>
> This check involves:
> - key->objectid check
> Basic alignment check.
>
> - key->type check
> Against btrfs_extent_item::type and SKINNY_METADATA feature.
>
> - key->offset alignment c
EXTENT_DATA_REF is a little like DIR_ITEM which contains hash in its
key->offset.
This patch will check the following contents:
- Key->objectid
Basic alignment check.
- Hash
Hash of each extent_data_ref item must match key->offset.
- Offset
Basic alignment check.
Signed-off-by: Qu Wenruo
For TREE_BLOCK_REF, SHARED_DATA_REF and SHARED_BLOCK_REF we need to
check:
| TREE_BLOCK_REF | SHARED_BLOCK_REF | SHARED_BLOCK_REF
--++-+--
key->objectid |Alignment | Alignment|Alignment
key->offset |An
This patch introduces the ability to check extent items.
This check involves:
- key->objectid check
Basic alignment check.
- key->type check
Against btrfs_extent_item::type and SKINNY_METADATA feature.
- key->offset alignment check for EXTENT_ITEM
- key->offset check for METADATA_ITEM
- it
Finally, we are going to add tree-checker support for extent items,
which includes:
- EXTENT_ITEM/METADATA_ITEM
Which futher contains inline backrefs of:
* TREE_BLOCK_REF
* SHARED_BLOCK_REF
* EXETNT_DATA_REF
* SHARED_DATA_REF
- TREE_BLOCK_REF
- SHARED_BLOCK_REF
- EXTENT_DATA_REF
generic_err(leaf, slot,
>> +"invalid root v2 generaetion, have %llu expect (0, %llu]",
>
> So (0, %llu] here means that it must be greater than zero, right? I'm
> not sure that everyone uses the same notatio
On Tue, Jul 16, 2019 at 05:00:34PM +0800, Qu Wenruo wrote:
> This patch will introduce ROOT_ITEM check, which includes:
> - Key->objectid and key->offset check
> Currently only some easy check, e.g. 0 as rootid is invalid.
>
> - Item size check
> Root item size is fixed.
>
> - Generation chec
e extent, not
directly related to the size.
In theory it is OK to have a large value, and put extra limitation
on RAM bytes may cause unexpected false alerts.
So in tree-checker, we only check if the file offset and num bytes
overflow.
Signed-off-by: Qu Wenruo
Signed-off-by: David Sterba
Signe
This patch will introduce ROOT_ITEM check, which includes:
- Key->objectid and key->offset check
Currently only some easy check, e.g. 0 as rootid is invalid.
- Item size check
Root item size is fixed.
- Generation checks
Generation, v2_generaetion and last_snapshot should not pass super
g
On Thu, May 30, 2019 at 08:03:48PM +0800, Qu Wenruo wrote:
> >> @@ -112,6 +112,7 @@ static int check_extent_data_item(struct extent_buffer
> >> *leaf,
> >>struct btrfs_file_extent_item *fi;
> >>u32 sectorsize = fs_info->sectorsize;
> >>u32 item_size = btrfs_item_size_nr(leaf, slot);
>
as file_offset + num_bytes should never go beyond u64
>> max.
>>
>> For ram_bytes part, it's about the decompressed size of the extent, not
>> directly related to the size.
>> In theory is OK to have super large value, and put extra
>> limitation on ram bytes may c
part, it's about the decompressed size of the extent, not
> directly related to the size.
> In theory is OK to have super large value, and put extra
> limitation on ram bytes may cause unexpected false alert.
>
> So in tree-checker, we only check if the file offset and num bytes
as file_offset + num_bytes should never go beyond u64
>> max.
>>
>> For ram_bytes part, it's about the decompressed size of the extent, not
>> directly related to the size.
>> In theory is OK to have super large value, and put extra
>> limitation on ram bytes may c
part, it's about the decompressed size of the extent, not
> directly related to the size.
> In theory is OK to have super large value, and put extra
> limitation on ram bytes may cause unexpected false alert.
>
> So in tree-checker, we only check if the file offset and num bytes
it traims file extent
> items). Therefore teach the tree checker to detect such cases. This is
> motivated by a recently fixed bug (race between ranged full fsync and
> writeback or adjacent ranges).
>
> Signed-off-by: Filipe Manana
Reviewed-by: Qu Wenruo
It's better than
_extents() when it traims file extent
> items). Therefore teach the tree checker to detect such cases. This is
> motivated by a recently fixed bug (race between ranged full fsync and
> writeback or adjacent ranges).
>
> Signed-off-by: Filipe Manana
Reviewed-by: Josef Bacik
Thanks,
Josef
From: Filipe Manana
Having file extent items with ranges that overlap each other is a serious
issue that leads to all sorts of corruptions and crashes (like a BUG_ON()
during the course of __btrfs_drop_extents() when it traims file extent
items). Therefore teach the tree checker to detect such
lue, and put extra
limitation on ram bytes may cause unexpected false alert.
So in tree-checker, we only check if the file offset and num bytes
overflow.
Signed-off-by: Qu Wenruo
---
fs/btrfs/tree-checker.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/fs/btrfs/tree-checker.c b/
On Thu, Apr 25, 2019 at 10:22:30PM +0800, Qu Wenruo wrote:
>
>
> On 2019/4/25 下午10:13, David Sterba wrote:
> > On Thu, Apr 25, 2019 at 08:30:38AM +0800, Qu Wenruo wrote:
> >>
> >>
> >> On 2019/4/25 上午1:45, David Sterba wrote:
> >>> On Wed, Apr 24, 2019 at 03:22:53PM +0800, Qu Wenruo wrote:
>
On 2019/4/25 下午10:13, David Sterba wrote:
> On Thu, Apr 25, 2019 at 08:30:38AM +0800, Qu Wenruo wrote:
>>
>>
>> On 2019/4/25 上午1:45, David Sterba wrote:
>>> On Wed, Apr 24, 2019 at 03:22:53PM +0800, Qu Wenruo wrote:
Allowing error injection for btrfs_check_leaf_full() and
btrfs_check_no
On Thu, Apr 25, 2019 at 08:30:38AM +0800, Qu Wenruo wrote:
>
>
> On 2019/4/25 上午1:45, David Sterba wrote:
> > On Wed, Apr 24, 2019 at 03:22:53PM +0800, Qu Wenruo wrote:
> >> Allowing error injection for btrfs_check_leaf_full() and
> >> btrfs_check_node() is useful to test the failure path of btrf
On 2019/4/25 上午1:45, David Sterba wrote:
> On Wed, Apr 24, 2019 at 03:22:53PM +0800, Qu Wenruo wrote:
>> Allowing error injection for btrfs_check_leaf_full() and
>> btrfs_check_node() is useful to test the failure path of btrfs write
>> time tree check.
>>
>> Signed-off-by: Qu Wenruo
>
> Does n
On Wed, Apr 24, 2019 at 03:22:53PM +0800, Qu Wenruo wrote:
> Allowing error injection for btrfs_check_leaf_full() and
> btrfs_check_node() is useful to test the failure path of btrfs write
> time tree check.
>
> Signed-off-by: Qu Wenruo
Added to misc-next, thanks.
On Wed, Apr 24, 2019 at 03:22:53PM +0800, Qu Wenruo wrote:
> Allowing error injection for btrfs_check_leaf_full() and
> btrfs_check_node() is useful to test the failure path of btrfs write
> time tree check.
>
> Signed-off-by: Qu Wenruo
Does not compile:
CC [M] fs/btrfs/tests/extent-map-test
Allowing error injection for btrfs_check_leaf_full() and
btrfs_check_node() is useful to test the failure path of btrfs write
time tree check.
Signed-off-by: Qu Wenruo
---
fs/btrfs/tree-checker.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/btrfs/tree-checker.c b/fs/btrfs/tree-check
On Sat, Apr 06, 2019 at 09:57:35AM +0800, Qu Wenruo wrote:
> >>>
> >>> This patchset also introduces a new optimization, where original empty
> >>> leaf owner check can be pretty expensive and cause false alerts for
> >>> write time tree checker.
&
|- btrfs_device_set_total_bytes(device, 0)
> > | |- btrfs_update_device()
> > | |- btrfs_commit_transaction() #1
> > |- btrfs_rm_dev_item()
> >
> > This will trigger write time tree checker warning.
> > And further more, this can create valid btrfs with devic
mmit_transaction() #1
> |- btrfs_rm_dev_item()
>
> This will trigger write time tree checker warning.
> And further more, this can create valid btrfs with device->total_bytes
> == 0 and triggering read time tree-checker if power loss happens after
> above transaction #1 but befo
checker warning.
And further more, this can create valid btrfs with device->total_bytes
== 0 and triggering read time tree-checker if power loss happens after
above transaction #1 but before next transaction.
So this dev item check is too restrict.
Please fold this patch into commit 87d87c6dc
+0200
>>>
>>> btrfs: Switch btrfs_trim_free_extents to find_first_clear_extent_bit
>>>
>>> These two patches changes the behavior of write time tree-checker, where
>>> the initial patches didn't check the content of the leaf, leaving memory
>&
remove this patch from misc-next queue.
Under the following call trace, we could create device with total_bytes
== 0;
btrfs_rm_device()
|- btrfs_shrink_device()
| |- btrfs_device_set_total_bytes(device, 0)
| |- btrfs_update_device()
| |- btrfs_commit_transaction() #1
|- btrfs_rm_dev_item()
Thi
xtent_bit
>>
>> These two patches changes the behavior of write time tree-checker, where
>> the initial patches didn't check the content of the leaf, leaving memory
>> bit flipping possible to sneak in.
>>
>> This patchset also introduces a new optimization, w
56a7b
> (david/misc-next-with-write-checks, david/misc-next)
> Author: Nikolay Borisov
> Date: Wed Mar 27 14:24:18 2019 +0200
>
> btrfs: Switch btrfs_trim_free_extents to find_first_clear_extent_bit
>
> These two patches changes the behavior of write time tree-checker
; However it's pretty expensive tree search to locate the owner root,
> > especially when it get reused by mandatory read and write time
> > tree-checker.
> >
> > This patch will remove that check, and completely rely on owner based
> > empty leaf check, which is
y expensive tree search to locate the owner root,
>> especially when it get reused by mandatory read and write time
>> tree-checker.
>>
>> This patch will remove that check, and completely rely on owner based
>> empty leaf check, which is much faster and still works fine
t get reused by mandatory read and write time
> tree-checker.
>
> This patch will remove that check, and completely rely on owner based
> empty leaf check, which is much faster and still works fine for most
> case.
>
> And since we skip the old root owner ch
1 - 100 of 300 matches
Mail list logo
