linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* superblock corruption, cannot obtain data
@ 2014-06-01  3:51 Shaun Reich
  2014-06-01  9:07 ` Duncan
  0 siblings, 1 reply; 4+ messages in thread
From: Shaun Reich @ 2014-06-01  3:51 UTC (permalink / raw)
  To: linux-btrfs

at some point, my /home randomly(?) went into -ro as i noticed writes
were not working. Checked dmesg which had some backtraces which i
ignored. So I simply rebooted, only to find out it wouldn't come back.

so now my /home is stuck on here, I was literally going to do my round
of backups tonight. It's not extremely critical..but to reproduce my
data it'll still be several hours of lost time..and the annoyances of
redoing it.

mounting results in this, as below. mounting recovery doesn't help.
mounting ro recovery doesn't help. btrfs fsck basically reaffirms what
I know so far, that I'm screwed because my superblock is bad.

show super: http://pastie.org/private/b1k2famcfmtquaqgpyfozg
mount dmesg: http://pastie.org/private/8zsczfustrmeg6a2bbfxag

btrfs-find-root: http://bpaste.net/show/326346

it's a 250gb fs.

so, how can i (a) extract my data, (b) try to get it working again,
without needing to redo the filesystem?

I could not understand how to use btrfs-recover with my problem. It
mostly seems to hate me because of said superblock issue.

I wasn't aware that the superblock was extremely critical (surely one
can recreate such data from existing data, theoretically?)

need any other info, just ask.

(please keep me cc'd, not sub'ed)


-- 
Shaun Reich,
KDE Software Developer (kde.org)

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

* Re: superblock corruption, cannot obtain data
  2014-06-01  3:51 superblock corruption, cannot obtain data Shaun Reich
@ 2014-06-01  9:07 ` Duncan
  0 siblings, 0 replies; 4+ messages in thread
From: Duncan @ 2014-06-01  9:07 UTC (permalink / raw)
  To: linux-btrfs

Shaun Reich posted on Sat, 31 May 2014 23:51:26 -0400 as excerpted:

> at some point, my /home randomly(?) went into -ro as i noticed writes
> were not working. Checked dmesg which had some backtraces which i
> ignored. So I simply rebooted, only to find out it wouldn't come back.
> 
> so now my /home is stuck on here, I was literally going to do my round
> of backups tonight. It's not extremely critical..but to reproduce my
> data it'll still be several hours of lost time..and the annoyances of
> redoing it.
> 
> mounting results in this, as below. mounting recovery doesn't help.
> mounting ro recovery doesn't help. btrfs fsck basically reaffirms what I
> know so far, that I'm screwed because my superblock is bad.
> 
> show super: http://pastie.org/private/b1k2famcfmtquaqgpyfozg mount
> dmesg: http://pastie.org/private/8zsczfustrmeg6a2bbfxag
> 
> btrfs-find-root: http://bpaste.net/show/326346

Hi, Shaun.  KDE user here, gentoo, USE=-semantic-desktop, active on the
kde general and linux lists (as well as here and the gentoo lists).  =:^)

How do you know it's a bad superblock?  While I'm not a dev just a list
regular, show-super looks reasonable from here, and find-root does find
what appears to be a good root.  From here the problem seems to be a bad
ctree (of several), not a bad superblock.

First thing to try is mounting with nospace_cache.  If that works, try
mounting with clear_cache and letting it work for a bit to rebuild.

If that doesn't work, it may simply be the log tree.  btrfs-zero-log is
used to fix that, but before you try that, read this entry in the FAQ and
follow the instructions for making a filesystem image to turn in to the
devs to help them fix such problems, and consider making a backup of the
damaged filesystem using dd/ddrescue, since the warning about making it
possibly more difficult to recover if this is NOT the problem applies:

https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#I_can.27t_mount_my_filesystem.2C_and_I_get_a_kernel_oops.21

With luck one of those options will help.  I know I had a space_cache
issue here myself, some time ago.  I've not had to run zero-log, but
I've seen a number of posters who found it helped.

Another thing to try is mounting recovery,ro.  A number of people have
reported that would work when simple recovery wouldn't, because when
it was writable btrfs would immediately try to fix the problem and
immediately fail.

Beyond that, you'll need more expert help.  But most of the time one
of those three works, so with luck...

-- 
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] 4+ messages in thread

* Re: superblock corruption, cannot obtain data
  2014-06-01 15:54 ` Shaun Reich
@ 2014-06-02 19:30   ` Shaun Reich
  0 siblings, 0 replies; 4+ messages in thread
From: Shaun Reich @ 2014-06-02 19:30 UTC (permalink / raw)
  To: linux-btrfs, Duncan

Tl;dr tried nearly everything, couldn't get it to recover, gave up and
restored my old backup. I was running the newest Archlinux kernel
release.

.. Extracting data with Btrfs restore was quite useless, Btrfs find
root didn't list any object id's either, which I was unsure why. I
guess I was just unlucky or the utility got changed since all the
other people I've seen had used it.

Still have a full dd image of the disk that I'll keep for a week or
so, and a Btrfs-image, if anyone is at all interested.

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

* Re: superblock corruption, cannot obtain data
       [not found] <20140601020750.0283af6c@ws>
@ 2014-06-01 15:54 ` Shaun Reich
  2014-06-02 19:30   ` Shaun Reich
  0 siblings, 1 reply; 4+ messages in thread
From: Shaun Reich @ 2014-06-01 15:54 UTC (permalink / raw)
  To: Duncan, linux-btrfs; +Cc: Shaun Reich

> How do you know it's a bad superblock?  While I'm not a dev just a list
> regular, show-super looks reasonable from here, and find-root does find
> what appears to be a good root.  From here the problem seems to be a bad
> ctree (of several), not a bad superblock.

yes i think you're right. i think that was just the initial thinking of #btrfs


>
> First thing to try is mounting with nospace_cache.  If that works, try
> mounting with clear_cache and letting it work for a bit to rebuild.

nope, same error.

>
> If that doesn't work, it may simply be the log tree.  btrfs-zero-log is
> used to fix that, but before you try that, read this entry in the FAQ
> and follow the instructions for making a filesystem image to turn in to
> the devs to help them fix such problems, and consider making a backup
> of the damaged filesystem using dd/ddrescue, since the warning about
> making it possibly more difficult to recover if this is NOT the problem
> applies:

tried this, btrfs-image complains about roughly the same error,
btrfs-zero-log said the following: http://bpaste.net/show/328495


> Another thing to try is mounting recovery,ro.  A number of people have
> reported that would work when simple recovery wouldn't, because when
> it was writable btrfs would immediately try to fix the problem and
> immediately fail.

nope, same error.

here's what happens when i run fsck http://cwillu.com:8080/74.84.235.22/3

"Critical roots corrupted, unable to fsck the FS" sounds like
especially good news ;p


--
Shaun Reich,
KDE Software Developer (kde.org)

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

end of thread, other threads:[~2014-06-02 19:30 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-01  3:51 superblock corruption, cannot obtain data Shaun Reich
2014-06-01  9:07 ` Duncan
     [not found] <20140601020750.0283af6c@ws>
2014-06-01 15:54 ` Shaun Reich
2014-06-02 19:30   ` Shaun Reich

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