On Fri, Mar 16, 2018 at 10:17 AM, Mike Stevens <michael.stevens@xxxxxxxxx> wrote: >> Also, in the meantime, maybe the problem can be prevented by >> preventing the balance from resuming when mounting. First umount then >> mount with -o skip_balance. > > Thanks for the suggestion Chris. I already had mounted it with skip_balance and then cancelled > the balance. It will mount, but any significant i/o to the volume cause it to drop r/o. It's getting confused and doesn't want to corrupt the file system, that's a good thing. Basically it wants to create a block group, but this fails. In the code, before it gets to the particular failure noted in the call trace, there are multiple different attempts to allocate a block group but those are also failing. But here's the thing - the scrub is still being started or resumed. I didn't think that scrubs are resumed automatically, but you've got >Mar 15 14:03:06 auswscs9903 kernel: scrub_enumerate_chunks+0x1ad/0x680 [btrfs] >Mar 15 14:03:06 auswscs9903 kernel: btrfs_scrub_dev+0x21d/0x540 [btrfs] and >Mar 15 14:03:06 auswscs9903 kernel: BTRFS warning (device sdag): failed setting block group ro: -30 These are only found in scrub.c Is there something starting the scrub right away at mount time? Is there enough time to cancel scrub before it goes read only? I definitely think there's a bug here somewhere, but it's taking more than one thing at once to trigger it, so it's a kind of corner case or it would have been caught sooner. See if you can prevent scrub from being started, or if it's resuming on its own for some reason then try to cancel it soon after mount, hopefully before it goes ro. Another thing you could try is mounting with nospace_cache. This is a coin toss if it will matter, but the fact it's not able to create pending bg's makes me wonder if possibly something is awry with the on disk free space cache, and this would eliminate that possibility without having to clear the cache. There's a performance penalty with nospace_cache but that's the least of the issues right now. -- 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
