| View previous topic :: View next topic |
| Author |
Message |
msst
Apprentice
Joined: 07 Jun 2011
Posts: 259
|
 Posted: Sun Jul 03, 2016 9:49 pm Post subject: Howto merge two LUKS-btrfs partitions? |
 |
|
| Code: | sdb 8:16 0 465,8G 0 disk
├─sdb2 8:18 0 12G 0 part
│ └─dswap 254:1 0 12G 0 crypt [SWAP]
├─sdb3 8:19 0 119,2G 0 part
│ └─_dev_sdb3 254:3 0 119,2G 0 crypt /home2
└─sdb4 8:20 0 307,1G 0 part
└─_dev_sdb4 254:2 0 307,1G 0 crypt /data |
Current setup on a disk. I want to discard sdb3 and add the space to sdb4, which I want to keep.
One way to achieve this would be
1. dd if=/dev/sdb4 of=/large/external/disk/sdb4.img
2. fdisk: d3, d4
3. fdisk: n3, max space
4. dd if=/large/external/disk/sdb4.img of=/dev/sdb3
5. cryptsetup open /dev/sdb3, cryptsetup resize
6. btrfs fi resize max
But I have no large external disk at hand and really do not want to copy 300 GB twice. It would be easy if sdb3 was bigger than sdb4, but it is not.
Does anyone see a chance to afford this change without a full backup of sdb4 partition? Could we manipulate sdb3 to span the disk to the end going into sdb4 without deleting sdb4? And then dd if=/dev/sdb4 of=/dev/sdb3 overwriting sdb4 start while the end of sdb4 is still being read?
I guess it comes down to the question how I can move the sdb4 partiton forward without backing it up in that scenario... |
|
| Back to top |
|
 |
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3131
|
| Posted: Mon Jul 04, 2016 9:13 pm Post subject: |
|
|
| Quote: | | Could we manipulate sdb3 to span the disk to the end going into sdb4 without deleting sdb4? |
Precisely what LVM is for. Now, you don't use LVM, so there is no high level interface for you. However, there is good news for you too. Bad news is, what I write below is actually walking a tightrope. Don't do that unless you really have to.
You can move your filesystem with dd. Pushing it towards the beginning is relatively easy (as long as you trust your power supply), just make sure buffer size is smaller than the offset. Ain't a big deal with an offset of roughly 120GB you would use. Hint: dd supports seek=<target offset> and skip=<source offset> params.
Please mind that doing it this way is risky. If copying is interrupted, you lose everything.
You could do that safer if you copied the partition one chunk at a time to another device and stored it's position at the drive and then copied it back to the target device (so you could resume copying the data from the point where it stopped), but it's going to be 2 times slower and harder to implement (you have to script it instead of just launching it).
A partition is just a pointer to your filesystem. If you want to move a filesystem, you will have to delete partitions and create them again with corrected offsets. If you fail at setting up offsets, kernel will not recognize your filesystem (and may accidentally damage it).
Once you moved filesystem and re-create partitions to point to it, you can proceed with extending the filesystem to let it consume the empty space behind.
Oh, and an important note: if you can't afford a full backup of those partitions, at least do a backup of your partition table and make sure your .history works. And store that .history in a safe place. This will give you a second chance in case you got the offsets wrong. |
|
| Back to top |
|
|
msst
Apprentice
Joined: 07 Jun 2011
Posts: 259
|
| Posted: Sat Jul 23, 2016 7:20 am Post subject: |
|
|
| Quote: | | Hint: dd supports seek=<target offset> and skip=<source offset> params. |
Ah, I see. You mean basically dd if=/dev/sdb of=/dev/sdb with the right seek= and skip= parameters? Clever, had not thought about that.
BTW: I have a network backup. Incremental and a bit slow for hundred of GBs unless in dire need... |
|
| Back to top |
|
|
frostschutz
Advocate
Joined: 22 Feb 2005
Posts: 2977
Location: Germany
|
| Posted: Sat Jul 23, 2016 7:37 am Post subject: |
|
|
btrfs itself should be able to span devices, no? so if you're willing to keep both LUKS containers around (and get them open somehow), you'd not have to move anything.
| Quote: | | You mean basically dd if=/dev/sdb of=/dev/sdb with the right seek= and skip= parameters? Clever, had not thought about that. |
That's extremely dangerous. In the wrong direction it won't work at all, in the right direction you are still overwriting data in-place, if this process is cancelled for any reason (power loss, crash, ...) you're in data loss limbo.
If you decide to go with it anyway, use a large blocksize (like bs=1G if you have that much free RAM) and iflag=fullblock. Normally such huge blocksizes make copy process slower (optimal blocksize is in the 64K-1M range) but from/to the same disk it reduces the amount of seeks the disk has to do.
Add status=progess so you always see how far along it is.
If you're unsure about seek= skip= parameters it's also possible to create loop devices with offset (losetup --offset in bytes), and then work with those loop devices; you can verify the offset is correct by luksDump the loop device. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3131
|
| Posted: Sat Jul 23, 2016 3:32 pm Post subject: |
|
|
| Quote: | | You mean basically dd if=/dev/sdb of=/dev/sdb with the right seek= and skip= parameters? Clever, had not thought about that. |
Yes, and if you have an additional persistent device, you could write a sort of log + current block to that device before you copy it back to the original device. If you sync after every write, you'll be able to resume in case your data move gets interrupted for any reason.
It's still dangerous to your data though. It's easy to make a mistake there, so _test_ your backup before you go this way 
Spanning a btrfs volume across devices may be a better idea. It will certainly be easier
| Quote: | | If you decide to go with it anyway, use a large blocksize (like bs=1G if you have that much free RAM) and iflag=fullblock. |
I don't know any tricks for specifying different block sizes for skip/seek and copy. The highest common will most likely be 1MB - Partitioning software tends to align partition borders at 1MB boundaries. And there is another pitfall here: make sure you use the same base in all cases. Partitioning software probably uses base 2. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Other Things Gentoo
