On Mon, Nov 13, 2017 at 8:45 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > On Mon, Nov 13, 2017 at 8:08 PM, Ben Hooper <ben@xxxxxxxxxxxxx> 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. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
