Convert ext4 lvm to normal ext4 partition

Michael Miles mmamiga6 at gmail.com
Fri Nov 12 23:57:25 UTC 2010


Peter Larsen wrote:
> 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.
>
>    
I was running bench mark software (Seeker) which showed the huge 
difference from benching the boot (187 seeks/second) to the lvm on the 
same disk at 66 seeks/second

That's a pretty big difference and it should not be


More information about the users mailing list