On Tue, Jun 20, 2017 at 9:44 AM, Marc MERLIN <m...@merlins.org> wrote:
> In the meantime, I ran into this again: > https://bugzilla.kernel.org/show_bug.cgi?id=195863 > btrfs check of a big filesystem kills the kernel due to OOM (but btrfs > userspace is not OOM killed) > > Is it achievable at all for btrfs check to realize that it's taking all the > available RAM in kernel space, is about to crash the system, and cancel the > check before the system crashes? > I've already confirmed that it doesn't use swap. I've just had to order new > RAM to upgrade my machine from 24GB to 32GB, but 32GB is max for that > hardware, so hopefully the lowmem repair stuff will work before I hit the > 32GB limit next time. Right now Btrfs isn't scalable if you have to repair it because large volumes run into this problem; one of the reasons for the lowmem mode. It's a separate bug that it OOMs even with swap, I don't know why it won't use that, it should be up to kernel memory management to deal with this; I know this works with xfs_repair. I don't know if the idea is that normal mode will go away, in favor of lowmem mode, or if there are fixes still planned for normal mode. If it's going to stick around, it needs to be able to use swap, same for lowmem mode. Just running into a total inability to --repair isn't OK. -- Chris Murphy -- 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
