linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).