All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roman Mamedov <rm@romanrm.net>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Cameron Kelley <cameronkelley28@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: Mount failing - unable to find logical
Date: Wed, 18 Oct 2017 10:10:52 +0500	[thread overview]
Message-ID: <20171018101052.3e5221af@natsu> (raw)
In-Reply-To: <93bfd00c-1ade-176d-0c0f-675fe904ab88@gmx.com>

On Wed, 18 Oct 2017 09:24:01 +0800
Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:

> 
> 
> On 2017年10月18日 04:43, Cameron Kelley wrote:
> > Hey btrfs gurus,
> > 
> > I have a 4 disk btrfs filesystem that has suddenly stopped mounting
> > after a recent reboot. The data is in an odd configuration due to
> > originally being in a 3 disk RAID1 before adding a 4th disk and running
> > a balance to convert to RAID10. There wasn't enough free space to
> > completely convert, so about half the data is still in RAID1 while the
> > other half is in RAID10. Both metadata and system are RAID10. It has
> > been in this configuration for 6 months or so now since adding the 4th
> > disk. It just holds archived media and hasn't had any data added or
> > modified in quite some time. I feel pretty stupid now for not correcting
> > that sooner though.
> > 
> > I have tried mounting with different mount options for recovery, ro,
> > degraded, etc. Log shows errors about "unable to find logical
> > 3746892939264 length 4096"
> > 
> > When I do a btrfs check, it doesn't find any issues. Running
> > btrfs-find-root comes up with a message about a block that the
> > generation doesn't match. If I specify that block on the btrfs check, I
> > get transid verify failures.
> > 
> > I ran a dry run of a recovery of the entire filesystem which runs
> > through every file with no errors. I would just restore the data and
> > start fresh, but unfortunately I don't have the free space at the moment
> > for the ~4.5TB of data.
> > 
> > I also ran full smart self tests on all 4 disks with no errors.
> > 
> > root@nas2:~# uname -a
> > Linux nas2 4.13.7-041307-generic #201710141430 SMP Sat Oct 14 14:39:06
> > UTC 2017 i686 i686 i686 GNU/Linux
> 
> I don't think i686 kernel will cause any difference, but considering
> most of us are using x86_64 to develop/test, maybe it will be a good
> idea to upgrade to x86_64 kernel?

Indeed a problem with mounting on 32-bit in 4.13 has been reported recently:
https://www.spinics.net/lists/linux-btrfs/msg69734.html
with the same error message.

I believe it's this patchset that is supposed to fix that.
https://www.spinics.net/lists/linux-btrfs/msg70001.html

@Cameron maybe you didn't just reboot, but also upgraded your kernel at the
same time? In any case, try a 4.9 series kernel, or a 64-bit machine if you
want to stay with 4.13.

-- 
With respect,
Roman

  parent reply	other threads:[~2017-10-18  5:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-17 20:43 Mount failing - unable to find logical Cameron Kelley
2017-10-18  1:24 ` Qu Wenruo
2017-10-18  3:22   ` Cameron Kelley
2017-10-18  4:36     ` Qu Wenruo
2017-10-18  5:10   ` Roman Mamedov [this message]
2017-10-18 16:40     ` SOLVED - 32-bit kernel 4.13 bug - " Cameron Kelley

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=20171018101052.3e5221af@natsu \
    --to=rm@romanrm.net \
    --cc=cameronkelley28@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.