Convert ext4 lvm to normal ext4 partition

[Peter Larsen]

On Fri, 2010-11-12 at 10:34 -0800, Michael Miles wrote:
> Patrick O'Callaghan wrote:
> > On 12/11/10 1:13 PM, Michael Miles wrote:
> >> Considering that the LVM is a ext4 Virtual partition it seems to me 
> >> that it would be easy to convert but there is no such beast out there
> >> Lots of stuff for converting ext3 to ext4 but nothing for what I need.

It's very easy to do; but why would you? LVM should be kept. It makes
your life easier and has no impact on performance. Copying from/to an
LVM is as easy/troublesome as copying to/from a partition. Use dd to
copy data from one to another. Between LVs, between partitions or
between LVs and partitions; both ways. 

In other words - there's no difference in the file system. ext4 is ext4.
Whether you have it on a USB stick, scsi, sata, partition or even raw -
the filesystem is the same. As long as there is room on the destination
device, you can copy it from any device type to another. This is not the
case for boot information (of course) but the file systems are the same.

> > This is pure speculation on my part, but I'm guessing one reason it's 
> > hard is that the LVM layer knows nothing about the ext4 layer. The 
> > ext4 layer contains lots of metadata (inodes, freelists, etc.) which 
> > includes pointers to disk sectors or extents. In a physical partition 
> > these point to real disk addresses but in an LVM partition they are 
> > virtual (compare real with virtual memory for an analogy). 

This is false and based on not understanding how device handling is
done. Device mapper is involved, with or without lvm. Your partition
layout is just as much an "abstract" layer as an LVM volume is. All the
kernel gets is the same mapping table between the logical to physical
addresses, that you do in your partition table. There's nothing in EXT*
that addresses physical addresses on your desk. Pretty much nothing does
these days.

> > From LVM's 
> > viewpoint the entire ext4 fs is just disk sectors with random binary 
> > data. The fact that some of this stuff is fs metadata and some isn't 
> > means that a conversion tool would need to understand the ext4 
> > metadata to convert it. Of course if it's ext3 or xfs or btrfs etc. 
> > then the same applies, with different rules for each one.

LVM has no "opinion" about anything that is inside the volume. That's up
to other layers. Just like your partition table doesn't care what file
system is created in a given partition. As you know, linux does not use
the MBR partition type flags at all. They're all there for your benefit
- nothing code wise.

> > Worse still, if you want a in-place conversion you have to be able to 
> > do this in such a way that it's recoverable even after a hard system 
> > crash in the middle of the conversion. And if you don't need it 
> > in-place, you already have the solution as said before.

If there is a crash in the dd, you just run dd again. If you're really
good, you can resume it from where it left off; worst case is you copy
everything again.

> > Just my 2 cents.
> >
> > poc
> Agreed, I am just really surprised that Fedora would adopt this method 
> of storage as it slows down the drive by a huge margin.
> That reason alone would say to me' No, don't want this"

HUGE MARGIN? Got any documentation to back that one up? There is no -
repeat NO - performance/difference in how the disk is addressed by LVM
or a partition. It's a simple mapping between logical and physical
addresses, that is done regardless of how you address your device.

-- 
-- 
Best Regards
  Peter Larsen

Wise words of the day:
I'm going to give my psychoanalyst one more year, then I'm going to Lourdes.
		-- Woody Allen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20101112/bc7e438f/attachment.bin