From: Chris Mason <chris.mason@oracle.com>
To: Peter Stuge <peter@stuge.se>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: resize ate my root node
Date: Thu, 10 Mar 2011 09:04:04 -0500 [thread overview]
Message-ID: <1299765769-sup-265@think> (raw)
In-Reply-To: <20110310134509.13787.qmail@stuge.se>
Excerpts from Peter Stuge's message of 2011-03-10 08:45:09 -0500:
> Chris Mason wrote:
> > Which tool and which version of the tool did you use to delete the
> > partition?
>
> fdisk from util-linux-2.18
Straight from util-linux, or with distro patches?
>
> The non-working partition was deleted and the current one created
> with fdisk from util-linux-2.14.2.
>
> > > It's a 64GB CF card with two partitions; one 40MB ext2 and "the rest"
> > > is btrfs. This is the current fdisk output:
> >
> > Ok, going back to your original email, the block you're failing on
> > is probably right in the middle of the drive.
>
> Right.
>
> > We can't be sure without looking at the mapping tree (which we
> > don't have),
>
> Could we guess at where it was put?
Until you do something funky like balance the drive, there's a 1:1
mapping. The easy way to guess is to strace btrfsck and see where it
read.
>
> > > I say current, because by now I have changed the sdb2 partition
> > > twice.
> >
> > Have you ever changed the start of the partition?
>
> No.
>
> > If the start had changed the superblock should be in the wrong
> > place, so the mount wouldn't have gotten this far.
>
> Right.
>
> > > In any case changing the partition table shouldn't affect the
> > > filesystem, right? Also, I changed the partition with the filesystem
> > > mounted, so the kernel did not start using the new partition table.
> >
> > I'd have to repeat the test on this flash card to say for sure.
> > Deleting then recreating the partition with the FS mounted isn't
> > very high up on the list of things that get tested often, so my
> > guess is that's where the problem is.
>
> As I understand it, fdisk writes the new partition table to disk, and
> asks the kernel to re-read it from there. That ioctl failed, I expect
> because the filesystem was mounted.
>
> > Right, we've got a block full with zeros where they don't belong.
> > Can you run dump the block contents with gdb please?
>
> Will do!
>
> > Ok, we talked about power offs and barriers in a different thread,
> > but I didn't realize you were on a CF device. I'd want to do some
> > tests on this device to see how well it really reacted in power
> > offs, but lets do that after we pull your data some where safer.
>
> I'm of course happy to help test anything!
Great, thanks.
-chris
next prev parent reply other threads:[~2011-03-10 14:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-07 17:48 resize ate my root node Peter Stuge
2011-03-08 21:40 ` Chris Mason
2011-03-10 6:23 ` Peter Stuge
2011-03-10 13:18 ` Chris Mason
2011-04-18 21:01 ` Peter Stuge
2011-05-03 13:23 ` Peter Stuge
2011-03-10 13:19 ` Chris Mason
2011-03-10 13:45 ` Peter Stuge
2011-03-10 14:04 ` Chris Mason [this message]
2011-04-18 21:12 ` Peter Stuge
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=1299765769-sup-265@think \
--to=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=peter@stuge.se \
/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).