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. Mike, For now, looks like we don't have a good way to work around the warning since it's hardcoded in the source, but more fine-grained balance is possible if that's what you're looking for. thanks, liubo -- 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
