All of lore.kernel.org
 help / color / mirror / Atom feed
From: "S. Fricke" <silvio.fricke@gmail.com>
To: Richard Michael <rmichael@edgeofthenet.org>
Cc: "Holger Hoffstätte" <holger.hoffstaette@googlemail.com>,
	"Linux Btrfs" <linux-btrfs@vger.kernel.org>
Subject: Re: problem with long running btrfs mount operation
Date: Tue, 22 Sep 2015 16:43:12 +0200	[thread overview]
Message-ID: <20150922144312.GB14395@sfserver> (raw)
In-Reply-To: <CABR0jERXQ9ydE+KAeQBrW5F0DzraePnAyz8m-uVStUCbeFt4WQ@mail.gmail.com>

Hi,

> On Tue, Sep 22, 2015 at 9:53 AM, Holger Hoffstätte
> <holger.hoffstaette@googlemail.com> wrote:
> > On 09/22/15 15:38, S. Fricke wrote:
> >> I have a problem with one of my btrfs hdds. If I mount it, it needs more than
> >> 135 minutes for this operation. After the mounting it works normaly. This is
> >> reproducible only with this hdd.
> >>
> >> Maybe someone has a clue what is going wrong here.
> >
> > On remount it tries to continue a previously started balance, which fails with
> > an error (as can be seen at the end of your log). You should:
> >
> > a) immediately stop what you're doing on that fs and unmount it
> > b) get btrfs-progs-4.2.1 (not 4.2) and see what it says

What should it say to me? I have to send a command? Should I try to mount the
device after I have unmount it? BTW: Is btrfs-progs needed for mounting?

> >
> > Depending on the outcome of b) you can use -o skip_balance on the next mount.
> >
> > -h
> 
> I'm curious, do the relevant INFO lines also appear earlier in the
> log, near the time the mount began?
> 
> These:
> 
> BTRFS: checking UUID tree
> [  +0.000076] BTRFS info (device sda1): continuing balance
> 
> 
> Otherwise, it requires an unknown amount of patience to diagnose this
> problem -- how long should I wait before giving up?
> 
> It seems to me, from a sysadmin's perspective, the log messages are
> reversed (hung task, 2+ hrs later, BTRFS tells me what it's doing) .
> I'd expect BTRFS to log a "continuing balance" message as soon as I
> mount it, then it's blocked [for as long as I care to wait], but I can
> immediately tell what's happened.

Thats my problem in general with btrfs, and other filesystems, I have a
glitch; I have to wait, but I have no possibilities to look what is going on
on drive X. Okay I could use sysemtaps, has someone good scripts for such
usecase? Or maybe we have other toolings?

Regards,
Silvio

-- 
-- S. Fricke ---------------------------------------- silvio@port1024.net --
   Diplom-Informatiker (FH)
   Linux-Entwicklung             JABBER: silvio@conversation.port1024.net   
----------------------------------------------------------------------------

  reply	other threads:[~2015-09-22 14:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-22 13:38 problem with long running btrfs mount operation S. Fricke
2015-09-22 13:53 ` Holger Hoffstätte
2015-09-22 14:31   ` Richard Michael
2015-09-22 14:43     ` S. Fricke [this message]
2015-09-22 14:57       ` Holger Hoffstätte
2015-09-22 15:13         ` Hugo Mills
2015-09-23  5:42         ` S. Fricke
2015-09-23  9:36           ` Holger Hoffstätte

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=20150922144312.GB14395@sfserver \
    --to=silvio.fricke@gmail.com \
    --cc=holger.hoffstaette@googlemail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=rmichael@edgeofthenet.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.