Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 12 down vote accepted

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.

share|improve this answer
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
I used it successfully to convert my 2 ext4 paritions totalling 120GB, the whole process took about 2 minutes and the result is pretty solid. Thanks for writing blocks! – Amr Mostafa Jul 28 '14 at 21:45
One caveat should be mentioned regarding blocks: it can convert regular volume to the LVM one, but if this volume was bootable, the great chance it will not boot after the procedure, if you will not do some GRUB reinstallation procedures manually. Should be mentioned in man or something, I believe. – TranslucentCloud Jan 19 '15 at 11:09
@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
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 at 16:17

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.


share|improve this answer

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!

share|improve this answer
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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .