Hi Linus,
We have two more fixes in my for-linus branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
I was hoping to also include a fix for a btrfs deadlock with compression
enabled, but we're still nailing that one down.
Liu Bo (1) commits (+11/-0):
Btrfs: fix abnormal long waiting in fsync
Eric Sandeen (1) commits (+4/-4):
btrfs: test for valid bdev before kobj removal in btrfs_rm_device
Total: (2) commits (+15/-4)
fs/btrfs/ordered-data.c | 11 +++++++++++
fs/btrfs/volumes.c | 8 ++++----
2 files changed, 15 insertions(+), 4 deletions(-)
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
trigger.
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