RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1052207 - btrfsck is unable to fix filesystem
Summary: btrfsck is unable to fix filesystem
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: btrfs-progs
Version: 7.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: fs-maint
QA Contact: Filesystem QE
URL:
Whiteboard:
Depends On: 1044456
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-13 13:49 UTC by Karel Volný
Modified: 2017-01-01 18:22 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1044456
Environment:
Last Closed: 2017-01-01 18:22:22 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
some illustration (2.00 MB, image/jpeg)
2017-01-01 18:17 UTC, Karel Volný
no flags Details

Description Karel Volný 2014-01-13 13:49:46 UTC
btrfsck pretends that it finished okay (returns zero), but the filesystem is not fixed

btrfs-progs-3.12-1.el7.x86_64


# btrfsck --repair --init-csum-tree --init-extent-tree btrfs ; echo $?
enabling repair mode
Creating a new CRC tree
parent transid verify failed on 29360128 wanted 80030 found 80039
parent transid verify failed on 29360128 wanted 80030 found 80039
parent transid verify failed on 29360128 wanted 80030 found 80039
parent transid verify failed on 29360128 wanted 80030 found 80039
Ignoring transid failure
parent transid verify failed on 4420636672 wanted 80040 found 80024
parent transid verify failed on 4420636672 wanted 80040 found 80024
parent transid verify failed on 4420636672 wanted 80040 found 80024
parent transid verify failed on 4420636672 wanted 80040 found 80024
Ignoring transid failure
Checking filesystem on btrfs
UUID: 9b9d89e3-3c2f-44ac-a1f6-0b0a1c730a08
Creating a new extent tree
Failed to find [29376512, 168, 4096]
btrfs unable to find ref byte nr 29376512 parent 0 root 1  owner 1 offset 0
Failed to find [29368320, 168, 4096]
btrfs unable to find ref byte nr 29368320 parent 0 root 1  owner 0 offset 1
checking extents
Reinit crc root
Failed to find [29372416, 168, 4096]
btrfs unable to find ref byte nr 29372416 parent 0 root 2  owner 0 offset 0
Failed to find [29364224, 168, 4096]
btrfs unable to find ref byte nr 29364224 parent 0 root 1  owner 1 offset 0
found 0 bytes used err is 0
total csum bytes: 0
total tree bytes: 0
total fs tree bytes: 0
total extent tree bytes: 0
btree space waste bytes: 0
file data blocks allocated: 0
 referenced 0
Btrfs v3.12
0

# btrfsck btrfs ; echo $?
parent transid verify failed on 29360128 wanted 80030 found 80041
parent transid verify failed on 29360128 wanted 80030 found 80041
parent transid verify failed on 29360128 wanted 80030 found 80041
parent transid verify failed on 29360128 wanted 80030 found 80041
Ignoring transid failure
parent transid verify failed on 4420636672 wanted 80042 found 80024
parent transid verify failed on 4420636672 wanted 80042 found 80024
parent transid verify failed on 4420636672 wanted 80042 found 80024
parent transid verify failed on 4420636672 wanted 80042 found 80024
Ignoring transid failure
Checking filesystem on btrfs
UUID: 9b9d89e3-3c2f-44ac-a1f6-0b0a1c730a08
checking extents
Block Group[0, 4194304] existed.
Block Group[4194304, 8388608] existed.
Block Group[12582912, 8388608] existed.
Block Group[20971520, 8388608] existed.
Block Group[29360128, 1073741824] existed.
Block Group[1103101952, 1073741824] existed.
Block Group[2176843776, 1073741824] existed
...
root 18446744073709551607 inode 22577938432 errors 1, no inode item
root 18446744073709551607 inode 23651680256 errors 1, no inode item
root 18446744073709551607 inode 24725422080 errors 1, no inode item
root 18446744073709551607 inode 25799163904 errors 1, no inode item
root 18446744073709551607 inode 18446744073709551607 errors 1, no inode item
warning line 2023
found 282614853 bytes used err is 1
total csum bytes: 0
total tree bytes: 281657344
total fs tree bytes: 281620480
total extent tree bytes: 4096
btree space waste bytes: 71128625
file data blocks allocated: 27803508736
 referenced 12237398016
Btrfs v3.12
1



+++ This bug was initially created as a clone of Bug #1044456 +++

Description of problem:
I had a hardware problem - the disk got disconnected and reconnected on the bus. Afterwards, kernel reported some oops and remounted the filesystem read-only. Everything worked, I could read any file without problem.
Unfortunately, after the reboot, I'm no longer able to mount the filesystem.
Trying to run btrfsck on it with various options, it is unable to repair the filesystem, although it pretends it did - repair ends without error, yet on subsequent run I get nonzero exit code (and bunch of errors on the console).

Version-Release number of selected component (if applicable):
btrfs-progs-3.12-1.fc19.x86_64

How reproducible:
always

Steps to Reproduce:
1. btrfsck --repair /the/path
2. btrfsck /the/path

Actual results:
1. although some problems are reported during the run, it ends with success
2. it reports errors and the filesystem is not mountable

Expected results:
everything gets fixed, no further errors

Additional info:
I got an image of the filesystem in question, but it is about 4 GB compressed / from 600 GB (almost empty) disk uncompressed ...
Unfortunately, as I haven't expected such issues, I did the copy only after messing with btrfsck --init-extent-tree and --init-csum-tree.
Is there any place I can upload it to for examination?

Comment 3 RHEL Program Management 2014-03-22 06:15:15 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 5 Eric Sandeen 2015-05-18 19:13:44 UTC
Moving some of Zach's bugs around - 

Is there any evidence left for this bug?  fs image, metadata image, etc still around?  Not that we've made progress thus far anyway, but without the image in question, it's not necessarily going to be fixable.

Since this bug was filed, I actually did more focused testing of intentionally corrupted filesystems and found btrfs to fail, in general.  Since I reported that upstream, at least some progress has been made ...

Comment 7 Karel Volný 2017-01-01 18:17:06 UTC
Created attachment 1236425 [details]
some illustration

Comment 8 Karel Volný 2017-01-01 18:22:22 UTC
sorry, somehow I had lost track of this and the b0rk3n disk image is gone ... during Christmas cleanup I have found a photo I believe to be relevant so I've attached it as a reminder of lost hope :-) and I'm closing this INSUFFICIENT_DATA as I am unable to re-test/reproduce

and btw, thanks Eric for your work on FS


Note You need to log in before you can comment on or make changes to this bug.