From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: umount waiting for 12 hours and still running
Date: Tue, 5 Nov 2013 14:20:41 +0000 (UTC) [thread overview]
Message-ID: <pan$70ff2$6c271d88$3a2794d1$837be634@cox.net> (raw)
In-Reply-To: 5278F5AA.60108@complete.org
John Goerzen posted on Tue, 05 Nov 2013 07:42:02 -0600 as excerpted:
> Hello,
>
> More than 12 hours ago, I tried to umount a btrfs filesystem. Something
> involving btrfs-cleaner and btrfs-transacti is still running, but I
> don't know what.
>
> I have noticed excessively long umount times before, and it is a
> significant concern for me.
>
> A bit of background:
>
> The filesystem in question involves two 2TB USB hard drives. It is 49%
> full. Data is RAID0, metadata is RAID1. The files stored on it are for
> BackupPC, meaning there are many, many directories and hardlinks. I
> would estimate 30 million inodes in use and many of them have dozens of
> hardlinks to them.
That's a bit of a problem for btrfs at this point, as you rightly mention.
> I thought perhaps converting metadata to raid0 would help. So I
> started a btrfs balance start -mconver=raid0 on it.
> Kernel 3.10 from Debian wheezy backports on i386.
There's a known bug with balance on current kernels related to pre-
allocated space (as with the systemd journal or torrent files with some
clients).
A patch is available and queued for 3.13 and then for stable (which
doesn't take patches unless they're in current mainline already), but
while 3.12 is out and the 3.13 commit window would normally be open,
Linus is taking a week off for travel without a good internet connection,
so the 3.13 kernel commit window is delayed a week. Which means this
patch is likely to be delayed a couple weeks before it reaches stable.
=:^(
Here's a link to the post with the patch:
[PATCH] Btrfs: relocate csums properly with prealloc extents
http://permalink.gmane.org/gmane.comp.file-systems.btrfs/28733
I'd suggest applying that to the latest 3.12 kernel and trying the
balance again. Unfortunately that means an unsafe reboot without a
remount read-only or unmount, but...
--
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
next prev parent reply other threads:[~2013-11-05 14:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-05 13:42 umount waiting for 12 hours and still running John Goerzen
2013-11-05 14:20 ` Duncan [this message]
2013-11-05 16:11 ` John Goerzen
2013-11-05 18:21 ` Duncan
-- strict thread matches above, loose matches on Subject: below --
2013-11-05 18:46 Tomasz Chmielewski
2013-11-05 18:53 ` John Goerzen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$70ff2$6c271d88$3a2794d1$837be634@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).