Moved partition via dd

Moved partition via dd

[André Schlichting]

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
   > sudo dd conv=notrunc bs=4096 iflag=fullblock if=/dev/sdc2 
skip=$((245547520-33024)) seek=0 of=/dev/sdc2

Afterwards I could succesfully open the dm-crypt container
   > cryptsetup luksOpen /dev/sdc2 data-ext

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 /dev/mapper/data-ext /mnt/data-ext/
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.

   > dmesg | tail
[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 --version
Btrfs v0.20-rc1-253-g7854c8b

   > btrfsck /dev/mapper/data-ext
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

   > dmesg | tail

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

   > btrfs-debug-tree /dev/mapper/data-ext > debug-tree.log 2> 
debug-tree.err

I ran also from the Problem-FAQ
   > btrfs-zero-log /dev/mapper/data-ext
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

   > dmesg | tail
[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

Re: Moved partition via dd

[Chris Murphy]

On Jun 8, 2013, at 8:47 AM, André Schlichting <andre@delorus.de> wrote:

> 
> 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
>  > sudo dd conv=notrunc bs=4096 iflag=fullblock if=/dev/sdc2 skip=$((245547520-33024)) seek=0 of=/dev/sdc2

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


Chris Murphy

Re: Moved partition via dd

[André Schlichting]

Am 09.06.2013 00:20, schrieb Chris Murphy:
>
> On Jun 8, 2013, at 8:47 AM, André Schlichting <andre@delorus.de> wrote:
>
>>
>> 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
>>   > sudo dd conv=notrunc bs=4096 iflag=fullblock if=/dev/sdc2 skip=$((245547520-33024)) seek=0 of=/dev/sdc2
>
> You ultimately moved the wrong data because bs=4096 for dd, yet the partition logical sectors are based on 512 bytes.
>
>
> 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.
 > fdisk -l /dev/sdc
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

Re: Moved partition via dd

[Chris Murphy]

On Jun 8, 2013, at 6:42 PM, André Schlichting <andre@delorus.de> wrote:

> 
> 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.
> > fdisk -l /dev/sdc
> 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

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

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

Re: Moved partition via dd

[André Schlichting]

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. The following 
error from btrfsck
 > Check tree block failed, want=959572647936, have=13587293097915834379
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?

Re: Moved partition via dd

[Hugo Mills]

[-- 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 --]

Re: Moved partition via dd

[André Schlichting]

>> 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).
Thank you for the clarification and background.

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

>> 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 will try this in practice again on a spare disk with some smaller 
partition.

>     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.
>
Actually, this disk will become my new backup drive. So everything save 
and I reformatted it already.

André

Re: Moved partition via dd

[Chris Murphy]

On Jun 9, 2013, at 6:44 AM, André Schlichting <andre@delorus.de> wrote:
> 
> /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.

The end points are different according to information provided:
>> The old partition had the sector boundaries: 245547520 - 732566527
>> I deleted this one and created a new one with boundaries: 33024 - 732566640

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.

> 
> 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?

I just did this without LUKS and it did work.


Chris Murphy