Chris Mason wrote: > Which tool and which version of the tool did you use to delete the > partition? fdisk from util-linux-2.18 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? > > 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! //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
