Re: 4.11.1: cannot btrfs check --repair a filesystem, causes heavy memory stalls

On 2017-05-23 14:32, Kai Krakow wrote: Am Tue, 23 May 2017 07:21:33 -0400 schrieb "Austin S. Hemmelgarn" : On 2017-05-22 22:07, Chris Murphy wrote: On Mon, May 22, 2017 at 5:57 PM, Marc MERLIN wrote: On Mon, May 22, 2017 at 05:26:25PM -0600, Chris

Re: 4.11.1: cannot btrfs check --repair a filesystem, causes heavy memory stalls

Am Tue, 23 May 2017 07:21:33 -0400 schrieb "Austin S. Hemmelgarn" : > On 2017-05-22 22:07, Chris Murphy wrote: > > On Mon, May 22, 2017 at 5:57 PM, Marc MERLIN > > wrote: > >> On Mon, May 22, 2017 at 05:26:25PM -0600, Chris Murphy wrote: > [...] >

Re: 4.11.1: cannot btrfs check --repair a filesystem, causes heavy memory stalls

On Mon, May 22, 2017 at 09:19:34AM +, Duncan wrote: > btrfs check is userspace, not kernelspace. The btrfs-transacti threads That was my understanding, yes, but since I got it to starve my system, including in kernel OOM issues I pasted in my last message and just referenced in

Re: 4.11.1: cannot btrfs check --repair a filesystem, causes heavy memory stalls

On Tue, May 23, 2017 at 07:21:33AM -0400, Austin S. Hemmelgarn wrote: > > Yeah although I have no idea how much swap is needed for it to > > succeed. I'm not sure what the relationship is to fs metadata chunk > > size to btrfs check RAM requirement is; but if it wants all of the > > metadata in

Re: 4.11.1: cannot btrfs check --repair a filesystem, causes heavy memory stalls

On 2017-05-22 22:07, Chris Murphy wrote: On Mon, May 22, 2017 at 5:57 PM, Marc MERLIN wrote: On Mon, May 22, 2017 at 05:26:25PM -0600, Chris Murphy wrote: On Mon, May 22, 2017 at 10:31 AM, Marc MERLIN wrote: I already have 24GB of RAM in that machine,

Re: 4.11.1: cannot btrfs check --repair a filesystem, causes heavy memory stalls

On Mon, May 22, 2017 at 5:57 PM, Marc MERLIN wrote: > On Mon, May 22, 2017 at 05:26:25PM -0600, Chris Murphy wrote: >> On Mon, May 22, 2017 at 10:31 AM, Marc MERLIN wrote: >> >> > >> > I already have 24GB of RAM in that machine, adding more for the real >> >

Re: 4.11.1: cannot btrfs check --repair a filesystem, causes heavy memory stalls

On Mon, May 22, 2017 at 05:26:25PM -0600, Chris Murphy wrote: > On Mon, May 22, 2017 at 10:31 AM, Marc MERLIN wrote: > > > > > I already have 24GB of RAM in that machine, adding more for the real > > fsck repair to run, is going to be difficult and ndb would take days I > >

Re: 4.11.1: cannot btrfs check --repair a filesystem, causes heavy memory stalls

On Mon, May 22, 2017 at 10:31 AM, Marc MERLIN wrote: > > I already have 24GB of RAM in that machine, adding more for the real > fsck repair to run, is going to be difficult and ndb would take days I > guess (then again I don't have a machine with 32 or 48 or 64GB of RAM >

Re: 4.11.1: cannot btrfs check --repair a filesystem, causes heavy memory stalls

On Sun, May 21, 2017 at 06:35:53PM -0700, Marc MERLIN wrote: > On Sun, May 21, 2017 at 04:45:57PM -0700, Marc MERLIN wrote: > > On Sun, May 21, 2017 at 02:47:33PM -0700, Marc MERLIN wrote: > > > gargamel:~# btrfs check --repair /dev/mapper/dshelf1 > > > enabling repair mode > > > Checking

Re: 4.11.1: cannot btrfs check --repair a filesystem, causes heavy memory stalls

Marc MERLIN posted on Sun, 21 May 2017 18:35:53 -0700 as excerpted: > On Sun, May 21, 2017 at 04:45:57PM -0700, Marc MERLIN wrote: >> On Sun, May 21, 2017 at 02:47:33PM -0700, Marc MERLIN wrote: >> > gargamel:~# btrfs check --repair /dev/mapper/dshelf1 enabling repair >> > mode Checking

Re: 4.11.1: cannot btrfs check --repair a filesystem, causes heavy memory stalls

On Sun, May 21, 2017 at 04:45:57PM -0700, Marc MERLIN wrote: > On Sun, May 21, 2017 at 02:47:33PM -0700, Marc MERLIN wrote: > > gargamel:~# btrfs check --repair /dev/mapper/dshelf1 > > enabling repair mode > > Checking filesystem on /dev/mapper/dshelf1 > > UUID:

Re: 4.11.1: cannot btrfs check --repair a filesystem, causes heavy memory stalls

On Sun, May 21, 2017 at 02:47:33PM -0700, Marc MERLIN wrote: > gargamel:~# btrfs check --repair /dev/mapper/dshelf1 > enabling repair mode > Checking filesystem on /dev/mapper/dshelf1 > UUID: 36f5079e-ca6c-4855-8639-ccb82695c18d > checking extents > > This causes a bunch of these: >

4.11.1: cannot btrfs check --repair a filesystem, causes heavy memory stalls

gargamel:~# btrfs check --repair /dev/mapper/dshelf1 enabling repair mode Checking filesystem on /dev/mapper/dshelf1 UUID: 36f5079e-ca6c-4855-8639-ccb82695c18d checking extents This causes a bunch of these: btrfs-transacti: page allocation stalls for 23508ms, order:0,