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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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/sdc2You ultimately moved the wrong data because bs=4096 for dd, yet the partition logical sectors are based on 512 bytes. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 bytesAhh, 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/sdc2You 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-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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''
>> 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é -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 - 732566640But 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-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html