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 -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
