On 2018年03月19日 06:52, waxhead wrote: > Liu Bo wrote: >> On Sat, Mar 17, 2018 at 5:26 PM, Liu Bo <obuil.li...@gmail.com> wrote: >>> On Fri, Mar 16, 2018 at 2:46 PM, Mike Stevens >>> <michael.stev...@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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
signature.asc
Description: OpenPGP digital signature
