Convert ext4 lvm to normal ext4 partition

Peter Larsen plarsen at famlarsen.homelinux.com
Fri Nov 12 21:15:12 UTC 2010


On Fri, 2010-11-12 at 16:34 -0430, Patrick O'Callaghan wrote:
> On 12/11/10 2:04 PM, 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.
> >>
> >> 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). 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.
> >>
> >> 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.
> >>
> >> 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"
> 
> Perhaps there are other benchmarks with different results, I don't know. 
> In any case, Fedora presumably decided that the gain in flexibility was 
> worth it. The irony is that there *is* a considerable gain for people 
> with large systems, server farms, clusters and what have you. For the 
> ordinary desktop user it's much more open to question, particularly as 
> some tools (notably parted) don't support it. Case in point: my F13 LVM 
> layout suffered a number of changes during its life, basically because I 
> needed to expand / at the expense of /home. The upshot was that the LV 
> containg / was physically (but not logically) split in two 
> non-contiguous regions. Then I decided to expand the /boot partition, 
> which of course is not in LVM. This meant resizing /, freeing space at 
> the end of the disk and moving the physical partition where LVM lived, 
> but of course parted refused since it doesn't understand LVM.

So you're opposed to LVM because you resizing physical partitions is a
problem?? You lost me.  As you point out, you have been able to resize
and move things around easily with LVM. There's a lot of other
advantages, but that should sell it for most desktop users. 

> I consulted Google, and this list, and a very knowledgeable friend, and 
> the LVM docs, and concluded that there was no avoiding messing with the 
> disk partition table via fdisk. Needless to say I lost everything. 
> Luckily I have a nightly backup to a NAS so the day was saved, and I 
> then got to do a completely clean install of F14. So maybe LVM is a Good 
> Thing after all :-)

Right - using hard partitions limits you. Getting rid of the hard
partitions is the goal. Once grub2 is the default boot manager for
Fedora we no longer need a /boot in a separate partition and these
problems are history.


-- 
-- 
Best Regards
  Peter Larsen

Wise words of the day:
 Fairlight: udp is the light margarine of tcp/ip transport protocols :)
	-- Seen on #Linux
-------------- 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/626cf2c7/attachment.bin 


More information about the users mailing list