linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Help ! "btrfs check" looping recursive
@ 2016-04-14 16:56 Swâmi Petaramesh
  2016-04-15  0:24 ` Duncan
  0 siblings, 1 reply; 3+ messages in thread
From: Swâmi Petaramesh @ 2016-04-14 16:56 UTC (permalink / raw)
  To: linux-btrfs

Hi folks,

It seems that i have a "btrfs check" process that’s stuck in an infinite
recursive loop…

How could I end this without breaking my filesystem ?

Help much needed & appreciated…

TIA.

Kind regards.


root@PartedMagic:~# btrfs check --repair /dev/VGZ/LINUX
enabling repair mode
Checking filesystem on /dev/VGZ/LINUX
UUID: 13c87f57-3a85-4daf-a4bf-ba777407c169
checking extents
Fixed 0 roots.
checking free space cache
cache and super generation don't match, space cache will be invalidated
checking fs roots
Deleting bad dir index [2188127,96,2152] root 267
Deleting bad dir index [2188127,96,2155] root 267
Deleting bad dir index [2188127,96,2152] root 40298
Deleting bad dir index [2188127,96,2155] root 40298
Deleting bad dir index [2188127,96,2152] root 40761
Deleting bad dir index [2188127,96,2155] root 40761
reset isize for dir 2188127 root 40815
Trying to rebuild inode:8089093
Can't determint the filetype for inode 8089093, assume it is a normal file
Can't get file name for inode 8089093, using '8089093' as fallback
Can't get file type for inode 8089093, using FILE as fallback
Moving file '8089093' to 'lost+found' dir since it has no valid backref
Fixed the nlink of inode 8089093
Trying to rebuild inode:8089098
Can't determint the filetype for inode 8089098, assume it is a normal file
Can't get file name for inode 8089098, using '8089098' as fallback
Can't get file type for inode 8089098, using FILE as fallback
Moving file '8089098' to 'lost+found' dir since it has no valid backref
Fixed the nlink of inode 8089098
Can't get file name for inode 8089093, using '8089093' as fallback
Moving file '8089093.8089093' to 'lost+found' dir since it has no valid
backref
Fixed the nlink of inode 8089093
root 40815 inode 8089093 errors 10, odd dir item
Can't get file name for inode 8089098, using '8089098' as fallback
Moving file '8089098.8089098' to 'lost+found' dir since it has no valid
backref
Fixed the nlink of inode 8089098
root 40815 inode 8089098 errors 10, odd dir item
Can't get file name for inode 8089093, using '8089093' as fallback
Moving file '8089093.8089093.8089093' to 'lost+found' dir since it has
no valid backref
Fixed the nlink of inode 8089093
root 40815 inode 8089093 errors 10, odd dir item
Can't get file name for inode 8089098, using '8089098' as fallback
Moving file '8089098.8089098.8089098' to 'lost+found' dir since it has
no valid backref
Fixed the nlink of inode 8089098
root 40815 inode 8089098 errors 10, odd dir item
Deleting bad dir index [2188127,96,2152] root 40815
Deleting bad dir index [2188127,96,2155] root 40815
reset isize for dir 2188127 root 40815
Can't get file name for inode 8089093, using '8089093' as fallback
Moving file '8089093.8089093.8089093.8089093' to 'lost+found' dir since
it has no valid backref
Fixed the nlink of inode 8089093
Can't get file name for inode 8089098, using '8089098' as fallback
Moving file '8089098.8089098.8089098.8089098' to 'lost+found' dir since
it has no valid backref
Fixed the nlink of inode 8089098
Can't get file name for inode 8089093, using '8089093' as fallback
Moving file '8089093.8089093.8089093.8089093.8089093' to 'lost+found'
dir since it has no valid backref
Fixed the nlink of inode 8089093
Can't get file name for inode 8089098, using '8089098' as fallback
Moving file '8089098.8089098.8089098.8089098.8089098' to 'lost+found'
dir since it has no valid backref
Fixed the nlink of inode 8089098
Deleting bad dir index [2188127,96,2152] root 40869
Deleting bad dir index [2188127,96,2155] root 40869
Can't get file name for inode 8089093, using '8089093' as fallback
Moving file '8089093.8089093.8089093.8089093.8089093.8089093' to
'lost+found' dir since it has no valid backref
Fixed the nlink of inode 8089093
Can't get file name for inode 8089098, using '8089098' as fallback
Moving file '8089098.8089098.8089098.8089098.8089098.8089098' to
'lost+found' dir since it has no valid backref
Fixed the nlink of inode 8089098
Can't get file name for inode 8089093, using '8089093' as fallback
Moving file '8089093.8089093.8089093.8089093.8089093.8089093.8089093' to
'lost+found' dir since it has no valid backref
Fixed the nlink of inode 8089093
Can't get file name for inode 8089098, using '8089098' as fallback
Moving file '8089098.8089098.8089098.8089098.8089098.8089098.8089098' to
'lost+found' dir since it has no valid backref
Fixed the nlink of inode 8089098
Can't get file name for inode 8089093, using '8089093' as fallback
Moving file
'8089093.8089093.8089093.8089093.8089093.8089093.8089093.8089093' to
'lost+found' dir since it has no valid backref
Fixed the nlink of inode 8089093
Can't get file name for inode 8089098, using '8089098' as fallback
Moving file
'8089098.8089098.8089098.8089098.8089098.8089098.8089098.8089098' to
'lost+found' dir since it has no valid backref
Fixed the nlink of inode 8089098
Deleting bad dir index [2188127,96,2152] root 40905
Deleting bad dir index [2188127,96,2155] root 40905
Can't get file name for inode 8089093, using '8089093' as fallback
Moving file
'8089093.8089093.8089093.8089093.8089093.8089093.8089093.8089093.8089093' to
'lost+found' dir since it has no valid backref
Fixed the nlink of inode 8089093
Can't get file name for inode 8089098, using '8089098' as fallback
Moving file
'8089098.8089098.8089098.8089098.8089098.8089098.8089098.8089098.8089098' to
'lost+found' dir since it has no valid backref
Fixed the nlink of inode 8089098
Can't get file name for inode 8089093, using '8089093' as fallback
Moving file
'8089093.8089093.8089093.8089093.8089093.8089093.8089093.8089093.8089093.8089093'
to 'lost+found' dir since it has no valid backref
Fixed the nlink of inode 8089093
Can't get file name for inode 8089098, using '8089098' as fallback
Moving file
'8089098.8089098.8089098.8089098.8089098.8089098.8089098.8089098.8089098.8089098'
to 'lost+found' dir since it has no valid backref
Fixed the nlink of inode 8089098
Deleting bad dir index [2188127,96,2152] root 41096
Deleting bad dir index [2188127,96,2155] root 41096
Can't get file name for inode 8089093, using '8089093' as fallback
Moving file
'8089093.8089093.8089093.8089093.8089093.8089093.8089093.8089093.8089093.8089093.8089093'
to 'lost+found' dir since it has no valid backref
Fixed the nlink of inode 8089093
Can't get file name for inode 8089098, using '8089098' as fallback
Moving file
'8089098.8089098.8089098.8089098.8089098.8089098.8089098.8089098.8089098.8089098.8089098'
to 'lost+found' dir since it has no valid backref
Fixed the nlink of inode 8089098

Ad lib…

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



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Help ! "btrfs check" looping recursive
  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
  0 siblings, 1 reply; 3+ messages in thread
From: Duncan @ 2016-04-15  0:24 UTC (permalink / raw)
  To: linux-btrfs

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…
> 
> How could I end this without breaking my filesystem ?

...

> root@PartedMagic:~# btrfs check --repair /dev/VGZ/LINUX
> enabling repair mode [...]


[Just a btrfs user and list regular myself, not a btrfs dev and not at a 
level to specifically answer the question.]

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.

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

(Tho in this specific context, kernel version isn't as useful as normal, 
since unlike many btrfs commands that simply call kernel code to do the 
real work, check code is all userspace.  But it's can't hurt to post it.  
Similarly, btrfs fi df to compliment btrfs fi show, or btrfs fi usage to 
output the same information as both, would in other contexts be useful, 
but they require a mounted filesystem, not something you can really even 
try with check running.)

Btrfs-progs version in particular, since the recursive nature of this 
loop is very obviously a bug.  If it's a current progs version, the bug 
may have been recently introduced.  If it's a dated version, the bug may 
have already been fixed.  (Either way, it may be that someone else will 
recognize the bug and tell you to try a later/earlier version, or if not, 
you very well may prompt a new patch, possibly after some further 
debugging.)

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Help ! "btrfs check" looping recursive
  2016-04-15  0:24 ` Duncan
@ 2016-04-15  9:13   ` Swâmi Petaramesh
  0 siblings, 0 replies; 3+ messages in thread
From: Swâmi Petaramesh @ 2016-04-15  9:13 UTC (permalink / raw)
  To: linux-btrfs

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2016-04-15  9:17 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 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).