Re: Moved partition via dd

[Hugo Mills <hugo@carfax.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 2931 bytes --]

On Sun, Jun 09, 2013 at 12:44:23PM +0200, André Schlichting wrote:
> Am 09.06.2013 00:57, schrieb Chris Murphy:
> >The next issue:
> >
> >>>if=/dev/sdc2 skip=$((245547520-33024)) seek=0 of=/dev/sdc2
> >
> >You have a skip (skip n block from input) value well inside of sdc2. It seems you should have skipped from sdc not sdc2, and should have used the old start value for sdc2 which was just 245547520, and you needed to specify a count value in order to get the correct number of blocks, which would have been 732566527-245547520. Then write those blocks to sdc2 (which makes seek= unnecessary).
> >
> >
> >Chris Murphy
> >
> 
> /dev/sdc2 at this moment was already the new partition with
> boundaries 33024 to 732566640 with the old partition inside.
> Therefore I used skip=old start - new start, which inside of sdc2
> points to the start of the old partition. I didn't worry about the
> count, because the partition was at the end of the disk.
> 
> I actually think that the move of the partition was no problem. I
> guess that btrfs has some absolute references which have to be
> adjusted and now has some problems with sectors not at the right
> place.

   No, it doesn't. All the position values in the FS are either
relative to the containing block device (i.e. the partition, in this
case), or are based on an internal virtual address space -- which is
itself mapped in terms of the containing block device(s).

> The following error from btrfsck
> > Check tree block failed, want=959572647936, have=13587293097915834379
> suggests that 959572647936 is a way off...

   That just says to me that you've got garbage metadata -- usually a
good indication that there's some file data where there should be
metadata, which would further suggest that you've somehow moved the
wrong data (or the right data into the wrong place).

> Maybe first, the principal question: Can one just move a
> btrfs-partition to the left by
> * delete partition
> * create partition moved
> * dd data from old to new partition
> Or does one have to adjust some references inside the btrfs filesystem?

   In theory, that process should be safe. In fact, I'm not aware of
*any* filesystem which is dependent on the position of the partition
within a larger device.

   I think at this point, you should try testdisk to see if it can
identify your FS's superblock. If that doesn't work, then restore from
backup is likely to be your fastest route to recovery.

   Hugo.

http://www.cgsecurity.org/wiki/TestDisk

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
    --- I get nervous when I see words like 'mayhaps' in a novel, ---    
                because I fear that just round the corner                
                          is lurking 'forsooth'                          

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]