On 2018年03月16日 23:03, Mike Stevens wrote: >> Can you post a more complete dmesg rather than snipping it? Is there >> anything device or Btrfs related in the 5 minutes before this trace >> happens? And is it still going read only? > > It's still going read only after the 4.15.10 update. Here's a lot more log: >
> Mar 15 14:01:14 auswscs9903 MR_MONITOR[1821]: <MRMON243> Controller ID: 0 > Fan speed changed on enclosure: 1 Fan#012 1 > Mar 15 14:03:06 auswscs9903 kernel: ------------[ cut here ]------------ > Mar 15 14:03:06 auswscs9903 kernel: WARNING: CPU: 6 PID: 2720 at > fs/btrfs/extent-tree.c:10192 btrfs_create_pending_block_groups+0x1f3/0x260 > [btrfs] > Mar 15 14:03:06 auswscs9903 kernel: BTRFS: error (device sdag) in > btrfs_create_pending_block_groups:10192: errno=-27 unknown -27 is EFBIG. And in the call trace of btrfs_create_pending_block_groups, I think it's triggered by btrfs_add_system_chunk(), which will return -EFBIG if a superblock can't contain that much system chunk entries. Furthermore, you have too many disks which dramatically increase the superblock system chunk array usage. If you're putting too many devices into one single btrfs and uses profile that utilize all disks like RAID0/10/5/6, then it will easily take up all space of superblock. Since even raid6 can only tolerant 2 disks failure, for so many disks it won't help much. It's recommended to use RAID10 for metadata and system chunk profiles, and reduce device number to a reasonable number. Thanks, Qu
signature.asc
Description: OpenPGP digital signature
