On 2017年11月14日 11:50, Chris Murphy wrote: > On Mon, Nov 13, 2017 at 8:45 PM, Chris Murphy <[email protected]> wrote: >> On Mon, Nov 13, 2017 at 8:08 PM, Ben Hooper <[email protected]> wrote: >> >>> [28205.454029] Code: 79 ff ff ff 49 8b 7c 24 60 89 da 48 c7 c6 68 c7 be a0 >>> 31 c0 e8 12 4e fe ff eb 9b 89 de 48 c7 c7 38 c7 be a0 31 c0 e8 53 11 5a e0 >>> <0f> ff eb 87 66 90 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 >>> [28205.456407] ---[ end trace 77358f42ce65a0d0 ]--- >>> [28205.457579] BTRFS: error (device sdl) in >>> btrfs_create_pending_block_groups:10254: errno=-27 unknown >>> [28206.172366] BTRFS: error (device sdl) in >>> btrfs_create_pending_block_groups:10254: errno=-27 unknown >>> [28206.178599] BTRFS warning (device sdl): Skipping commit of aborted >>> transaction. >>> [28206.179840] BTRFS: error (device sdl) in cleanup_transaction:1873: >>> errno=-5 IO failure >>> [28206.256720] BTRFS error (device sdl): pending csums is 1368064 >> >> The mysterious -27. But then also IO failure. Are there any other >> storage related kernel messages in the ~2 to 5 minutes prior to this >> trace? I'm wondering if there's something misbehaving: cable, >> controller, drive, other. >> > > Found a similar trace from July 2015 that Omar ran into and Filipe > thought he was close to tracking it down. It was also a pretty big > file system. Maybe they have an idea here. But btrfs check blowing up > isn't good in any case.
The BUG_ON in btrfs check is pretty obvious, btrfs check --repair runs out of space. Of course, you won't hit it if using default btrfs check which is readonly. IIRC I have submitted patch to make it end more gracefully. Thanks, Qu > > >
signature.asc
Description: OpenPGP digital signature
