linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Unmountable btrfs filesystem - 'unable to find logical' / 'no mapping'
Date: Wed, 16 Jul 2014 08:00:04 +0000 (UTC)	[thread overview]
Message-ID: <pan$1a915$ec9d1e93$7b7c14f1$dea1f150@cox.net> (raw)
In-Reply-To: CABibBbuGtAC7Rpptdd_wF7m87MSqg8zUEHvWSFsfk3KH+w2Jmg@mail.gmail.com

Gareth Clay posted on Tue, 15 Jul 2014 14:35:22 +0100 as excerpted:

> I noticed yesterday that the mount points on my btrfs RAID1 filesystem
> had become read-only. On a reboot, the filesystem fails to mount. I
> wondered if someone here might be able offer any advice on how to
> recover (if possible) from this position?

I had a similar (but I think different) issue some weeks ago.  It was my 
first real experience with btrfs troubleshooting and recovery.

First, the recommendation is do NOT do btrfs check --repair except either 
at the recommendation of a dev after they've seen the details and 
determined it can fix them, or if your next step would be a new mkfs of 
the filesystem, thus blowing away what's there anyway, so you've nothing 
to lose.  You can try btrfs check (aka btrfsck) without --repair to see 
what it reports as that's read-only and thus won't break anything 
further, but similarly, won't repair anything either.

Also, as a general recommendation, try a current kernel as btrfs is still 
developing fast enough that if you're a kernel series behind, there's 
fixes in the new version that you won't have in older kernels.  I see 
you're on an ubuntu 3.13 series kernel, and the recommendation would be 
the latest 3.15 series stable kernel, if not the 3.16-rc series 
development kernel, since that's past rc5 now and thus getting close to 
release.

The userspace, btrfs-progs, isn't quite as critical, but running at least 
v3.12 (which you are), is recommended.  FWIW, v3.14.2 is current (as of 
when I last checked a couple days ago anyway) and is what I am running 
here.

In general, you can try mounting with recovery and then with recovery,ro 
options, but that didn't work here.  You can also try with the degraded 
option (tho I didn't), to see if it'll mount with just one of the pair.

Of course, btrfs is still not fully stable and keeping current backups is 
recommended.  I did have backups, but they weren't as current as I wanted.

Beyond that, there's btrfs restore (a separate btrfs-restore executable 
in older btrfs-progs, part of the main btrfs executable in newer 
versions), which is what I ended up using and is what the rest of this 
reply is about.  That does NOT mount or write to the filesystem, but DOES 
let you pull files off the unmounted filesystem and write them to a 
working filesystem (btrfs or other, it was reiserfs here) in ordered to 
recover what you can.  You can use --dry-run to list files that would be 
recovered in ordered to get an idea of how much it can recover.

There's a page on the wiki about using btrfs recover in combination with 
btrfs-find-root, if the current root is damaged and won't let you recover 
much.  Note that "generation" and "transid" refer to the same thing, and 
you want to specify the root (using the -t location option, with the 
location found using find-root) that lets you recover the most.  The -l 
(list tree roots) option is also useful in this context.

https://btrfs.wiki.kernel.org/index.php/Restore

Of course restoring in this manner means you have to have somewhere else 
to put what you restore, which was fine for me as I'm using relatively 
small independent btrfs filesystems and could restore to a larger 
reiserfs on a different device, but could be rather tougher for large 
multi-terabyte filesystems, unless you have (or purchase) a spare disk to 
put it on.

One thing I did NOT realize until later, however, is that btrfs restore 
loses the user and permissions information (at least without -x, which 
says it restores extended attributes, I didn't try it with that).  I 
hacked up a find script to compare the restore to the backup and set 
ownership/permissions appropriately based on the files in the backup, but 
of course that didn't help for files that were new since the backup, and 
I had to set their ownership/permissions manually.

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


  reply	other threads:[~2014-07-16  8:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-15 13:35 Unmountable btrfs filesystem - 'unable to find logical' / 'no mapping' Gareth Clay
2014-07-16  8:00 ` Duncan [this message]
2014-07-17 23:09   ` Gareth Clay
2014-07-18 10:01     ` Duncan

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='pan$1a915$ec9d1e93$7b7c14f1$dea1f150@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --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 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).