All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Swâmi Petaramesh" <swami@petaramesh.org>
To: linux-btrfs@vger.kernel.org
Subject: Re: Help ! "btrfs check" looping recursive
Date: Fri, 15 Apr 2016 11:13:13 +0200	[thread overview]
Message-ID: <5710B0A9.1030800@petaramesh.org> (raw)
In-Reply-To: <pan$9e5b6$4adde6c7$caa17ba5$f91d4445@cox.net>

Hi there,

Thanks for your reply Duncan !

Le 15/04/2016 02:24, Duncan wrote :
> Swâmi Petaramesh posted on Thu, 14 Apr 2016 18:56:29 +0200 as excerpted:
> 
>> It seems that i have a "btrfs check" process that’s stuck in an infinite
>> recursive loop…

> Given the prompt above, you're running from parted-magic, but that 
> doesn't tell us the btrfs-progs or kernel versions unless we look it up.

True, I forgot to specify this.

This FS is from a machine that currently runs : 4.5.0-1-ARCH

As I had a couple of "dead" files (KDE session files in
~/.config/session) that showed "????" for all their attributes and
couldn’t be accessed nor deleted, I ran "btrfs check" from a reasonably
recent live Parted Magic, which has :

- Kernel : 4.3.2
- BTRFS tools : 4.1.2

> So kernel and btrfs-progs version?  Also, btrfs filesystem show output 
> might be useful.

Taken from the currently running machine (as I in the end choosed to
abort the "btrfs check" using ^C) :

# btrfs fi sh
Label: 'LINUX'  uuid: 13c87f57-3a85-4daf-a4bf-ba777407c169
        Total devices 1 FS bytes used 268.07GiB
        devid    1 size 334.50GiB used 294.54GiB path /dev/mapper/VGZ-LINUX


# btrfs fi df /
Data, single: total=289.46GiB, used=264.17GiB
System, DUP: total=32.00MiB, used=56.00KiB
Metadata, single: total=5.01GiB, used=3.90GiB
GlobalReserve, single: total=512.00MiB, used=0.00B


# btrfs fi us /
Overall:
    Device size:                 334.50GiB
    Device allocated:            294.54GiB
    Device unallocated:           39.96GiB
    Device missing:                  0.00B
    Used:                        268.07GiB
    Free (estimated):             65.26GiB      (min: 45.28GiB)
    Data ratio:                       1.00
    Metadata ratio:                   1.00
    Global reserve:              512.00MiB      (used: 0.00B)





Data,single: Size:289.46GiB, Used:264.17GiB


   /dev/mapper/VGZ-LINUX         289.46GiB





Metadata,single: Size:5.01GiB, Used:3.90GiB


   /dev/mapper/VGZ-LINUX           5.01GiB

System,DUP: Size:32.00MiB, Used:56.00KiB
   /dev/mapper/VGZ-LINUX          64.00MiB

Unallocated:
   /dev/mapper/VGZ-LINUX          39.96GiB


# df -h /
Sys. de fichiers      Taille Utilisé Dispo Uti% Monté sur
/dev/mapper/VGZ-LINUX   335G    269G   66G  81% /

> Btrfs-progs version in particular, since the recursive nature of this 
> loop is very obviously a bug.


I hope I gave all the necessary information now.

TIA and best regards.

ॐ

-- 
Swâmi Petaramesh <swami@petaramesh.org> PGP 9076E32E

      reply	other threads:[~2016-04-15  9:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-14 16:56 Help ! "btrfs check" looping recursive Swâmi Petaramesh
2016-04-15  0:24 ` Duncan
2016-04-15  9:13   ` Swâmi Petaramesh [this message]

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=5710B0A9.1030800@petaramesh.org \
    --to=swami@petaramesh.org \
    --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 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.