13

I'm currently doing cp -aR to copy data from my (99% full) 1TB ext4 formatted disk to a new LVM-with-ext4-on-it disk. It's taking forever.

Is there any way to attempt to "convert" the disk in place? I'm on EC2 so backing up takes minutes.

Or alternatively, is there any way that might be faster than cp to directly copy the ext4 filesystem onto the LVM disk?

Improve this question
26

I wrote blocks (née lvmify) which does this conversion in-place. It works by shrinking the filesystem a bit, moving the start of the filesystem to the end of the partition, and copying an LVM superblock (preconfigured with the right PV/LV/VG) in its place.

Improve this answer
9
  • this sounds really interesting! I am thinking on backuping my 500GB to the other partition (that is already lvm) just to give it a try!
    – Aquarius Power
    May 27 '14 at 0:01
  • 1
    @Gabriel, will this work on live fs? I mean do I need to unmount the FS, and then it does it in-place, or will it even work on a r/w mounted root FS?
    – Gavriel
    Jun 7 '15 at 11:20
  • 1
    @AmrMostafa: "Pretty" solid? I have this thing about my file systems, I need them to be rock solid... :-)
    – T.J. Crowder
    Jul 13 '15 at 15:09
  • 3
    Ubuntu Trusty+ users will find it hard to install the required python 3.3.. only 3.4 is available and blocks hasn't been updated since Dec 2014 :/
    – bksunday
    Jan 29 '16 at 16:17
  • 2
    Despite the fact that it was updated 5 ears ago, it steel working. Confirmed on NVMe SSD, GPT partition scheme. Note: better use Python 3.6.
    – tosh
    Aug 26 '18 at 11:19
1

I'm unsure about how to convert the disk live, but I think rsync will be a better and safer way to copy your data over. It'll allow you to resume and keep the data intact in the event the transfer stops.

I did find a similar process completed by someone adding an external drive to their local system as an LVM. There's not a whole lot of information, but I think it will be enough to get your started:

"So today I discovered the awesome that is LVM. Installing Debian, I selected "LVM - Use entire disk". But the main drive was a slow and small 5200rpm laptop drive. Today I inserted my spare 1.5TB drive and booted up. Wanted the system on this bigger faster drive instead.

LVM approach: add /dev/sdc to the volume group, then run "pvmove /dev/sda". This moves all data from sda to other drives (only sdc available). No need to reboot, no need to unmount. While I'm writing this, the data is being moved.

Later, do "vgreduce megatron /dev/sda" to remove the slow drive from the volume group and voila. Data moved. (megatron is the name of the volume group and of my computer). This might be old news to many but I just thought this was really cool :)"

Granted this was done locally, but I think with additional research, you maybe be able to accomlpish this.

source

Improve this answer
1

No method exists to do such an LVM conversion "on the fly."

LVM actually resides under your filesystem to expand it across multiple physical devices, or stripe or mirror it, etc. The final step in creating a logical volume is to lay a file system on top of it. Here are examples from RHEL6.

What you will need to do is back up or archive the data on that device, then destroy existing filesystem, create a logical volume, and re-lay a filesystem on top. If this is a root filesystem on a linux OS, consider doing a reinstallation. It may be faster.

For faster copies, I'm fond of dd, but I don't use it often. Making a mistake with dd is dangerous. One thing you can try is tar czv <source fs> | (cd <destination fs>; tar x) which will transfer a compressed tar file on the fly.

Good luck!

Improve this answer
4
  • 3
    Using compression in the tar operation makes no sense at all. The only place the data will be compressed is in-memory as it's piped; it's then immediately uncompressed again before it gets written to disk. Only now, the operation generates multiple times as much CPU load because it's both compressing and uncompressing, uselessly, on the fly. Also, for any operation like this involving entire filesystems, you're going to want at least tar cSf - | tar xvpf - to handle sparse files & permissions. Possibly --selinux too (if the destination volume will subsequently replace the source).
    – FeRD
    Oct 9 '13 at 7:05
  • That's a good point if your source and destination devices are on the same host or if you don't have CPU cycles to spare. Those are points to consider case by case. I do like the "S" and "p" switches and the "--selinux" argument.
    – dafydd
    Oct 10 '13 at 13:15
  • Mmm, well, if anyone's cloning a filesystem by piping an on-the-fly tar operation over a network link, then (a) they're a braver soul than I, but (b) you might NOT want -p unless the hosts share usernames/UIDs (though the manpage reminds me that -p is the default for GNU tar when run as root), and --selinux is fraught with even more peril — probably better to just do a restorecon -Rv (or -Rp) over the whole thing once it's mounted in the correct (final) location.
    – FeRD
    Oct 13 '13 at 8:43
  • dd is the proper tool for this operation since you're copying a partition. dd will make an exact copy on the new partition, then you change the fstab to load from the new partition instead of the old. Once you're done moving all the partitions off the old drive, you can destroy the filesystem and add the drive to the LVM physical disks group, and then use the space to expand the partitions however you wish.
    – Jeter-work
    Nov 20 '17 at 20:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.