Moved partition via dd

I did the following experiment and tried to move a dm-cryped btrfs partition to the left on an external 3TB drive.

The old partition had the sector boundaries: 245547520 - 732566527

I deleted this one and created a new one with boundaries: 33024 - 732566640

Now I moved the data

skip=$((245547520-33024)) seek=0 of=/dev/sdc2

Afterwards I could succesfully open the dm-crypt container

The idea was now to mount the btrfs filesystem and resize it to fill up the whole new partition. But the mounting of the btrfs filesystem failed with following errors

mount: wrong fs type, bad option, bad superblock on /dev/mapper/data-ext,
missing codepage or helper program, or other error

In some cases useful info is found in syslog - try dmesg | tail or so.

[51666.228722] device label data-ext devid 1 transid 2088 /dev/mapper/data-ext
[51666.230327] btrfs: disk space caching is enabled
[51666.256347] btrfs bad tree block start 13587293097915834379 959572647936
[51666.256854] btrfs bad tree block start 15898041577671574353 959572647936
[51666.256863] Failed to read block groups: -5
[51666.262707] btrfs: open_ctree failed

Btrfs v0.20-rc1-253-g7854c8b

Check tree block failed, want=959572647936, have=13587293097915834379 Check tree block failed, want=959572647936, have=13587293097915834379 Check tree block failed, want=959572647936, have=15898041577671574353 Check tree block failed, want=959572647936, have=13587293097915834379 Check tree block failed, want=959572647936, have=13587293097915834379 read block failed check_tree_block
Check tree block failed, want=615210135552, have=9470612182821228052 Check tree block failed, want=615210135552, have=9470612182821228052 Check tree block failed, want=615210135552, have=11515627140616528497 Check tree block failed, want=615210135552, have=11515627140616528497 Check tree block failed, want=615210135552, have=11515627140616528497 read block failed check_tree_block
Checking filesystem on /dev/mapper/data-ext
UUID: eba8eac6-836f-4664-b8b7-e2a405772e5a
checking extents

[51738.639126] btrfsck[15851]: segfault at 1d3 ip 0000000000413ed0 sp 00007fff52494e40 error 4 in btrfsck[400000+4d000]

debug-tree.err

I ran also from the Problem-FAQ

Check tree block failed, want=959572647936, have=13587293097915834379 Check tree block failed, want=959572647936, have=13587293097915834379 Check tree block failed, want=959572647936, have=15898041577671574353 Check tree block failed, want=959572647936, have=13587293097915834379 Check tree block failed, want=959572647936, have=13587293097915834379 read block failed check_tree_block
Check tree block failed, want=615210135552, have=9470612182821228052 Check tree block failed, want=615210135552, have=9470612182821228052 Check tree block failed, want=615210135552, have=11515627140616528497 Check tree block failed, want=615210135552, have=11515627140616528497 Check tree block failed, want=615210135552, have=11515627140616528497 read block failed check_tree_block

[52362.222122] btrfs-zero-log[16113]: segfault at 1d3 ip 0000000000401e11 sp 00007fff2f214060 error 4 in btrfs-zero-log[400000+2b000]
[52362.367331] device label data-ext devid 1 transid 2088 /dev/dm-4

You ultimately moved the wrong data because bs=4096 for dd, yet the partition logical sectors are based on 512 bytes.

Chris Murphy

Am 09.06.2013 00:20, schrieb Chris Murphy:

I'm not sure, but this external disk has a GPT with sector size 4096 and as I wrote the dm-crypted LUKS container can be opened without complains.

WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.

Disk /dev/sdc: 3000.6 GB, 3000592982016 bytes, 732566646 sectors Units = Sektoren of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk label type: gpt

#         Start          End    Size  Type            Name
 1            6        32773    128M  Microsoft reserved partition
 2        33024    732566640    2,7T  Linux filesystem

André Schlichting

Ahh, one of the new 4kN drives, interesting. So in that case bs=4096 is OK.

The next issue:

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

Am 09.06.2013 00:57, schrieb 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. The following error from btrfsck

suggests that 959572647936 is a way off...

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?

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

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

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'                          

Thank you for the clarification and background.

Seems like, that this happened and I actually also know how/when. I started moving the partition with my Laptop. But after the first projection of the time needed to move 2TB on USB2 speed, I decided to move the partition with a PC. So I stopped dd and tried to get the last sector position and continued on the Desktop with this position as "skip" value. I'm pretty sure, that there I did some mistake. That is also the reason, why the Luks-Header was intact.

I will try this in practice again on a spare disk with some smaller partition.

Actually, this disk will become my new backup drive. So everything save and I reformatted it already.

André

The end points are different according to information provided:

But also, the containing LUKS volume hasn't been grown yet. I wonder if it's a problem for the LUKS container to be on a much larger partition, not yet resized, and yet made active.

It seems the LUKS volume was found and opened, which means all of its metadata is intact, but the resulting mounted (decrypted) block device is corrupt, although even though the LUKS device hasn't been resized I'd think you should still be able to mount the existing file system, but the resize wouldn't have been possible without first resizing the LUKS device.

I just did this without LUKS and it did work.

Chris Murphy