Help ! "btrfs check" looping recursive
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…
Signature · 1 line
Swâmi Petaramesh <[email protected]> http://petaramesh.org PGP 9076E32E
Swâmi Petaramesh posted on Thu, 14 Apr 2016 18:56:29 +0200 as excerpted:
Quoted 4 lines
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 ?
...
Quoted 2 lines
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.)
Signature · 3 lines
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
Hi there,
Thanks for your reply Duncan !
Quoted 7 lines · Duncan
Swâmi Petaramesh posted on Thu, 14 Apr 2016 18:56:29 +0200 as excerpted:
Quoted 2 lines
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
Quoted 2 lines
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% /
Quoted 2 lines
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.
ॐ
Signature · 1 line
Swâmi Petaramesh <[email protected]> PGP 9076E32E