lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 21 Jul 2014 03:07:06 +0000 (UTC)
From:	Duncan <>
Subject: Re: [GIT PULL] Btrfs

Chris Mason posted on Sun, 20 Jul 2014 10:33:24 -0400 as excerpted:

> I was hoping to also include a fix for a btrfs deadlock with compression
> enabled, but we're still nailing that one down.

FWIW, I might be (rarely but twice, now) hitting that one myself, 
compress=lzo, but /not/ with the rsync that has been your current primary 

The last time I hit it, it was trying to start firefox shortly after a 
fresh boot.  Firefox didn't come up, and when I tried starting it again, 
I got the dialog saying it was already running, quit the running instance 
and try again, or reboot.

But the running firefox instance was stuck unkillable in D state, with a 
zombie child.  Three of my six cores were stuck in 100% IO-wait.

I finished what I was doing and shut down X, but of course the D-state 
and zombie firefox reparented to systemd.  The time before when that 
happened with firefox, I ended up losing several of the firefox state 
files and it forgot my extensions, which I had to restore from backup.  
So this time I mounted a reiserfs I use for other things and did a backup 
of the entire ~/.mozilla/ subdir before finishing the shutdown and 
reboot.  That backup went fine (surprised me, I thought it might hang 
too), and I umounted the reiserfs.  But when I went to finish the 
shutdown of course the affected btrfs wouldn't umount due to the stuck 
firefox.  So I did the magic-SRQ REISUB thing, and saw the emergency sync 
and the remount-read-only complete.

After that I force-rebooted.  Luckily, this time I didn't need that 
backup of the ~/.mozilla subfolder I had made -- firefox came up fine 
after the reboot.  But I did lose the read state on a few messages in my 
feed (rss/atom) and news (nntp) readers, so I think btrfs did lose the 
log from after the last root-tree commit point.

Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists