linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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