On 2018年07月18日 08:24, Marc MERLIN wrote:
> On Wed, Jul 18, 2018 at 08:05:51AM +0800, Qu Wenruo wrote:
>> No OOM triggers? That's a little strange.
>> Maybe it's related to how kernel handles memory over-commit?
>
> Yes, I think you are correct.
>
>> And for the hang, I think it's related to
On Wed, Jul 18, 2018 at 10:42:21PM +0300, Andrei Borzenkov wrote:
> > Any help from other experienced developers would definitely help to
> > solve why memory of 'btrfs check' is not swapped out or why OOM killer
> > is not triggered.
>
> Almost all used memory is marked as "active" and active
18.07.2018 03:05, Qu Wenruo пишет:
>
>
> On 2018年07月18日 04:59, Marc MERLIN wrote:
>> Ok, I did more testing. Qu is right that btrfs check does not crash the
>> kernel.
>> It just takes all the memory until linux hangs everywhere, and somehow (no
>> idea why)
>> the OOM killer never triggers.
On Wed, Jul 18, 2018 at 08:05:51AM +0800, Qu Wenruo wrote:
> No OOM triggers? That's a little strange.
> Maybe it's related to how kernel handles memory over-commit?
Yes, I think you are correct.
> And for the hang, I think it's related to some memory allocation failure
> and error handler just
On 2018年07月18日 04:59, Marc MERLIN wrote:
> Ok, I did more testing. Qu is right that btrfs check does not crash the
> kernel.
> It just takes all the memory until linux hangs everywhere, and somehow (no
> idea why)
> the OOM killer never triggers.
No OOM triggers? That's a little strange.
Ok, I did more testing. Qu is right that btrfs check does not crash the kernel.
It just takes all the memory until linux hangs everywhere, and somehow (no idea
why)
the OOM killer never triggers.
Details below:
On Tue, Jul 17, 2018 at 01:32:57PM -0700, Marc MERLIN wrote:
> Here is what I got
On Tue, Jul 17, 2018 at 10:50:32AM -0700, Marc MERLIN wrote:
> I got the following on 4.17.6 while running btrfs check --repair on an
> unmounted filesystem (not the lowmem version)
>
> I understand that btrfs check is userland only, although it seems that
> it caused these FS hangs on a
