Re: Crashes running btrfs scrub

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3570 bytes --]



On 2018年03月19日 06:52, waxhead wrote:
> Liu Bo wrote:
>> On Sat, Mar 17, 2018 at 5:26 PM, Liu Bo <obuil.liubo@gmail.com> wrote:
>>> On Fri, Mar 16, 2018 at 2:46 PM, Mike Stevens
>>> <michael.stevens@bayer.com> wrote:
>>>>> Could you please paste the whole dmesg, it looks like it hit
>>>>> btrfs_abort_transaction(),
>>>>> which should give us more information about where goes wrong.
>>>>
>>>> The whole thing is here https://pastebin.com/4ENq2saQ
>>>
>>> Given this,
>>>
>>> [  299.410998] BTRFS: error (device sdag) in
>>> btrfs_create_pending_block_groups:10192: errno=-27 unknown
>>>
>>> it refers to -EFBIG, so I think the warning comes from
>>>
>>> btrfs_add_system_chunk()
>>> {
>>> ...
>>>          if (array_size + item_size + sizeof(disk_key)
>>>
>>>                          > BTRFS_SYSTEM_CHUNK_ARRAY_SIZE) {
>>>
>>>                  mutex_unlock(&fs_info->chunk_mutex);
>>>
>>>                  return -EFBIG;
>>>
>>>          }
>>>
>>> If that's the case, we need to check this earlier during mount.
>>>
>>
>> I didn't realize this until now,  we do have a limitation on up to how
>> many disks btrfs could handle, in order to make balance/scrub work
>> properly (where system chunks may be set readonly),
>>
>> ((BTRFS_SYSTEM_CHUNK_ARRAY_SIZE / 2) - sizeof(struct btrfs_chunk)) /
>> sizeof(struct btrfs_stripe) + 1
>>
>> will be the number of disks btrfs can handle at most.
> 
> Am I understanding this correct, BTRFS have limit to the number of
> physical devices it can handle?! (max 30 devices?!)

Not exactly.

System chunk array is only used to store system chunk (tree blocks of
chunk tree).
For data chunks, it's completely unrelated.

And for certain system chunk type (raid1/dup) it's fixed to have 2
stripes for each chunk, so it won't take so much space.


Furthermore, system chunk should not be that much, as it's only
containing chunk tree.
For large fs, one chunk can be up to 10G for data or 1G for metadata.

10TB only needs about 100 chunk items, which doesn't even need to
allocate extra system chunk space.


But if one is using RAID0/5/6/10, it's pretty possible one will hit that
device number max.
But that's still pretty strange.
Correct calculation should be (I hardly see more than 2 system chunks in
real world)

2048 = 80 + 32 + 80 + n * 32 (For old mkfs which still has temporary sys
chunk)

Or

2048 = 80 + n * 32 (For new mkfs which doesn't have temporary sys chunk)

n should be the total number of disks if using RAID0/10/5/6 as metadata
profile.

So n will be 58, which is quite large at least for mkfs time limit.

Although for runtime, especially for relocation case, we need half of
the system chunk array to store the new system chunk, which makes the
number half.

But it should still be possible if we convert system chunk profile from
RAID0/10/5/6 to RAID1, which only takes 80 + 32 * 2.

Thanks,
Qu


> 
> Or are this referring to the number of devices BTRFS can utilize in a
> stripe (in which case 30 actually sounds like a high number).
> 
> 30 devices is really not that much, heck you get 90 disks top load JBOD
> storage chassis these days and BTRFS does sound like an attractive
> choice for things like that.
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]