Re: [PATCH] Btrfs: fix compressed write corruption on enospc

[Martin Steigerwald <Martin@lichtvoll.de>]

[-- Attachment #1: Type: text/plain, Size: 2710 bytes --]

Am Mittwoch, 6. August 2014, 09:35:51 schrieb Chris Mason:
> On 08/06/2014 06:21 AM, Martin Steigerwald wrote:
> >> I think this should go to stable. Thanks, Liu.
> 
> I'm definitely tagging this for stable.
> 
> > Unfortunately this fix does not seem to fix all lockups.
> 
> The traces below are a little different, could you please send the whole
> file?

Will paste it at the end.
 
> > Just had a hard lockup again during java-bases CrashPlanPROe app backuping
> > company data which is stored on BTRFS via ecryptfs to central Backup
> > server.
> > 
> > It basically happened on about the first heavy write I/O occasion after
> > the BTRFS trees filled the complete device:
> > 
> > I am now balancing the trees down to lower sizes manually with
> > 
> > btrfs balance start -dusage=10 /home
> > 
> > btrfs balance start -musage=10 /home
> > 
> > and raising values. BTW I got out of space with trying both at the same
> > time:
> > 
> > merkaba:~#1> btrfs balance start -dusage=10 -musage=10 /home
> > ERROR: error during balancing '/home' - No space left on device
> > There may be more info in syslog - try dmesg | tail
> > 
> > merkaba:~#1> btrfs fi sh /home
> > Label: 'home'  uuid: […]
> > 
> >         Total devices 2 FS bytes used 128.76GiB
> >         devid    1 size 160.00GiB used 146.00GiB path /dev/dm-0
> >         devid    2 size 160.00GiB used 146.00GiB path
> >         /dev/mapper/sata-home
> > 
> > So I am pretty sure meanwhile that hangs can best be trigger *if* BTRFS
> > trees fill the complete device.
> > 
> > I will try to keep tree sizes down as a work-around for now even it if
> > means additional write access towards the SSD devices.
> > 
> > And make sure tree sizes stay down on my first server BTRFS as well
> > although this uses debian backport kernel 3.14 and thus may not be
> > affected.
> > 
> > Are there any other fixes to try out? I really like to see this resolved.
> > Its in two stable kernel revisions already: 3.15 and 3.16. And by this it
> > means if not fixed next Debian stable (Jessie) will be affected by it.
> > 
> > 
> > Some kern.log (have stored the complete file)
[…]

Attached, xz compressed, since 180 KB as plaintext in a mail is a bit much.

This is complete from today resuming from hibernation today morning, the BTRFS 
hang, the reboot and the first balancing runs to make BTRFS more stable again.

Interestingly it was ecryptfs reporting issues before the BTRFS hang got 
reported. There are several a bit different looking traces in there.

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #2: kern.log.xz --]
[-- Type: application/x-xz, Size: 23596 bytes --]