Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On Wed, 24 Jun 2015 14:06:19 -0500 Chris Adams li...@cmadams.net wrote: Now, if btrfs ever gets all the kinks worked out (and has a stable fsck for the corner cases), it integrates volume management into the filesystem, which makes some of the management easier. I used AdvFS on DEC/Compaq/HP Tru64 Unix, which had some of that, and it made some of this easier/faster/smoother. Btrfs may eventually obsolete a lot of uses of LVM, but that's down the road. https://en.wikipedia.org/wiki/AdvFS AdvFS uses a relatively advanced concept of a storage pool (called a file domain) and of logical file systems (called file sets). A file domain is composed of any number of block devices, which could be partitions, LVM or LSM devices. I really miss this. BR, Bob ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On Fri, Jun 26, 2015 at 4:47 AM, Steve Clark scl...@netwolves.com wrote: On 06/25/2015 06:44 PM, Chris Murphy wrote: I did a bunch of testing of Raw, qcow2, and LV backed VM storage circa Fedora 19/20 and found very little difference. What mattered most was the (libvirt) cache setting, accessible by virsh edit the xml config or virt-manager through the GUI. There have been a lot of Which setting did you find most effective? In terms of performance, unsafe. Overall, it's hard to say because it's so configuration and use case specific. In my case, I do lots of Fedora installs, and Btrfs related testing, and the data I care about is safeguarded other ways. So I care mainly about VM performance, and therefore use unsafe. I haven't yet lost data in a way attributable to that setting (top on the list is user error, overwhelmingly, haha). You might find this useful: https://rwmj.wordpress.com/2013/09/02/new-in-libguestfs-allow-cache-mode-to-be-selected/ And this: https://github.com/libguestfs/libguestfs/commit/749e947bb0103f19feda0f29b6cbbf3cbfa350da Of particular annoyance to me in Virt-Manager is the prolific use of the word Default which doesn't tell you diddly. The problem is Virt-Manager supports different hypervisors and all of them can have different defaults which don't necessarily propagate through to libvirt and I'm not sure that libvirt is even able to be aware of all of them. So we get this useless placeholder called default. Default is not good just because you don't know what it is. It's not necessarily true that default translates into what's recommended - that may be true, but it may also not be ideal for your use case. -- Chris Murphy ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
Am 26.06.2015 um 12:47 schrieb Steve Clark scl...@netwolves.com: On 06/25/2015 06:44 PM, Chris Murphy wrote: Gordon Messmer gordon.messmer at gmail.com Wed Jun 24 01:42:13 UTC 2015 I wondered the same thing, especially in the context of someone who prefers virtual machines. LV-backed VMs have *dramatically* better disk performance than file-backed VMs. I did a bunch of testing of Raw, qcow2, and LV backed VM storage circa Fedora 19/20 and found very little difference. What mattered most was the (libvirt) cache setting, accessible by virsh edit the xml config or virt-manager through the GUI. There have been a lot of Which setting did you find most effective? Keep in mind - write caching can improve perf but also increases data loss on abnormal VM shutdowns -- LF ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On 06/26/2015 07:58 AM, Mark Milhollan wrote: On Wed, 24 Jun 2015, Gordon Messmer wrote: 1) If you have a system with a single disk, you have to reboot to add partitions for new guests. Linux won't refresh the partition table on the disk it boots from. I'm not sure this is still true, but I use LVM almost everywhere so I seldom need to try. It's definitely still true on CentOS 7. 3) If you want redundancy, partitions on top of RAID is more complex than LVM on top of RAID. As far as I know, partitions on top of RAID are subject to the same limitation as in #1. They look the same to me, and share the same limitations (WRT the PV). Create a RAID1 volume on two drives. Partition that volume. Where is your partition table? Is it in a spot where your BIOS/UEFI or another OS will see it? Will that non-Linux system try to open or modify the partitions inside your RAID? It depends on what metadata version you use. If you set this up in Anaconda, it's going to be version 0.90, and your partition table will be in a spot where a non-Linux system will read it. There's no ambiguity with LVM. That's what I mean when I say that it's less complicated. The format of MBR and GPT partition tables are imposed by the design of BIOS and UEFI. There is no good reason to use them for any purpose other than identifying the location of a filesytem that BIOS or UEFI must be able to read. The limitation I was referring to was that as far as I know, if Linux has mounted filesystems from a partitioned RAID set, you can't modify partitions without rebooting. That limitation doesn't affect LVM. Either can be partitioned but making more LVs is indeed simpler than using DM to partition a partition or MD. I'd like to use LVM RAID and never again have RAIDed partitions, so that I can choose the RAID level per LV, alas LVM RAID MDs don't appear in /proc/mdstat so monitoring them is somewhat more annoying. 4) As far as I know, Anaconda can't set up a logical volume that's a redundant type, so LVM on top of RAID is the only practical way to support redundant storage of your host filesystems. Anaconda has many deficiencies and indeed I am annoyed enough with it that I often skip trying to use its new disk manager, but making the PV on an MD RAID isn't impossible I know, that's what I said was the only practical way to support redundant storage (when using LVM). , or alternatively making the LVs redundant after install is a single command (each) and you can choose whether it should be mere mirroring or some MD manged RAID level (modulo the LVM RAID MD monitoring issue). I hadn't realized that. That's an interesting alternative to MD RAID, particularly for users who want LVs with different RAID levels. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On Fri, Jun 26, 2015 at 10:51 AM, Gordon Messmer gordon.mess...@gmail.com wrote: , or alternatively making the LVs redundant after install is a single command (each) and you can choose whether it should be mere mirroring or some MD manged RAID level (modulo the LVM RAID MD monitoring issue). I hadn't realized that. That's an interesting alternative to MD RAID, particularly for users who want LVs with different RAID levels. LVM RAID uses the md kernel code, but is managed by LVM tools and metadata rather than mdadm and its metadata format. It supports all the same RAID levels these days. The gotcha is that it's obscure enough that you won't find nearly as much documentation or help when you arrive at DR, what to do. And anyone who lurks on the linux-raid@ list knows that a huge pile of data loss comes from users who do the wrong thing; maybe top on the list is they for some ungodly reason read somewhere to use mdadm -C to overwrite mdadm metadata on one of their drives and this obliterates important information needed for recovery and now they actually have caused a bigger problem. At the moment, LVM RAID is only supported with conventional/thick provisioning. So if you want to do software RAID and also use LVM thin provisioning, you still need to use mdadm (or hardware RAID). -- Chris Murphy ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On 6/26/2015 12:34 PM, Chris Murphy wrote: At the moment, LVM RAID is only supported with conventional/thick provisioning. So if you want to do software RAID and also use LVM thin provisioning, you still need to use mdadm (or hardware RAID). You can do thin pools as RAID[1,5,N], just not in a single command: |root #||lvcreate -m 1 --type raid1 -l40%VG -n thin_pool vg0 | |root #||lvcreate -m 1 --type raid1 -L4MB -n thin_meta vg0 | |root #||lvconvert --thinpool vg0/thin_pool --poolmetadata vg00/thin_meta So yeah, it's not directly supported by the tools but it does work. I would not recommend it though as I doubt it is very well tested. | ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On 06/25/2015 06:44 PM, Chris Murphy wrote: Gordon Messmer gordon.messmer at gmail.com Wed Jun 24 01:42:13 UTC 2015 I wondered the same thing, especially in the context of someone who prefers virtual machines. LV-backed VMs have *dramatically* better disk performance than file-backed VMs. I did a bunch of testing of Raw, qcow2, and LV backed VM storage circa Fedora 19/20 and found very little difference. What mattered most was the (libvirt) cache setting, accessible by virsh edit the xml config or virt-manager through the GUI. There have been a lot of Which setting did you find most effective? optimizations in libvirt and qemu that make qcow2 files perform comparable to LVs. For migrating VMs, it's easier if they're a file. And qcow2 snapshots are more practical than LVM (thick) snapshots. The thin snapshots are quite good though they take a lot of familiarity with setting them up. -- Stephen Clark *NetWolves Managed Services, LLC.* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On 06/25/2015 01:20 PM, Chris Adams wrote: ...It's basically a way to assemble one arbitrary set of block devices and then divide them into another arbitrary set of block devices, but now separate from the underlying physical structure. Regular partitions have various limitations (one big one on Linux being that modifying the partition table of a disk with in-use partitions is a PITA and most often requires a reboot), and LVM abstracts away some of them. I'll give an example. I have a backup server, and for various reasons (hardlinks primarily) all the data needs to be in a single filesystem. However, this is running on an older VMware ESX server, and those have a 2TB LUN size limit. So, even though my EMC Clariion arrays can deal with 10TB LUNs without issue, the VMware ESX and all of its guests cannot. So, I have a lot of RDMs for the guests. The backup server's LVM looks like this: [root@backup-rdc ~]# pvscan PV /dev/sdd1 VG vg_opt lvm2 [1.95 TB / 0free] PV /dev/sde1 VG vg_opt lvm2 [1.95 TB / 0free] PV /dev/sdf1 VG vg_opt lvm2 [1.95 TB / 0free] PV /dev/sda2 VG VolGroup00 lvm2 [39.88 GB / 0free] PV /dev/sdg1 VG bak-rdclvm2 [1.95 TB / 0free] PV /dev/sdh1 VG bak-rdclvm2 [1.95 TB / 0free] PV /dev/sdi1 VG bak-rdclvm2 [1.95 TB / 0free] PV /dev/sdj1 VG bak-rdclvm2 [1.95 TB / 0free] PV /dev/sdk1 VG bak-rdclvm2 [1.47 TB / 0free] PV /dev/sdl1 VG bak-rdclvm2 [1.47 TB / 0free] PV /dev/sdm1 VG bak-rdclvm2 [1.95 TB / 0free] PV /dev/sdn1 VG bak-rdclvm2 [1.95 TB / 0free] PV /dev/sdo1 VG bak-rdclvm2 [1.95 TB / 0free] PV /dev/sdp1 VG bak-rdclvm2 [1.95 TB / 0free] PV /dev/sdq1 VG bak-rdclvm2 [1.95 TB / 0free] PV /dev/sdr1 VG bak-rdclvm2 [1.95 TB / 0free] PV /dev/sdb1 VG bak-rdclvm2 [1.95 TB / 0free] PV /dev/sdc1 VG bak-rdclvm2 [1.95 TB / 0free] Total: 18 [32.27 TB] / in use: 18 [32.27 TB] / in no VG: 0 [0 ] [root@backup-rdc ~]# lvscan ACTIVE'/dev/vg_opt/lv_backups' [5.86 TB] inherit ACTIVE'/dev/VolGroup00/LogVol00' [37.91 GB] inherit ACTIVE'/dev/VolGroup00/LogVol01' [1.97 GB] inherit ACTIVE'/dev/bak-rdc/cx3-80' [26.37 TB] inherit [root@backup-rdc ~]# It's just beautiful the way I can take another 1.95 TB LUN, add it to the volume group, expand the logical volume, and then expand the underlying filesystem (XFS) and just dynamically add storage. Being on an EMC Clariion foundation, I don't have to worry about the RAID, either, as the RAID6 and hotsparing is done by the array. SAN and LVM were made for each other. And, if and when I either migrate the guest over to physical hardware on the same SAN or migrate to some other virtualization, I can use LVM's tools to migrate from all those 1.95 and 1.47 TB LUNs over to a few larger LUNs and blow away the smaller LUNs while the system is online. And the EMC Clariion FLARE OE software allows me great flexibility in moving LUNs around in the array for performance and other reasons. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On 06/23/2015 01:54 PM, Marko Vojinovic wrote: So the story ended up with lots of people in upgrading griefs purely because they couldn't resize the separate /boot partition, and it was separate because LVM was present, and LVM was present with the goal of making partition resizing easy! A textbook example of a catch-22, unbelievable!! The Fedora /boot upsize was something I handled relatively easily with the LVM tools and another drive. I actually used an eSATA drive for this, but an internal or a USB external (which would have impacted system performance) could have been used. Here's what I did to resize my Fedora /boot when the upgrade required it several years back: 1.) Added a second drive that was larger than the drive that /boot was on; 2.) Created a PV on that drive; 3.) Added that PV to the volume group corresponding to the PV on the drive with /boot; 4.) Did a pvmove from the PV on the drive with /boot to the second drive (which took quite a while); 5.) Removed the PV on the drive with /boot from the volume group; 6.) Deleted the partition that previously contained the PV; 7.) Resized the /boot partition and its filesystem (this is doable while online, whereas resizing / online can be loads of fun); 8.) Created a new PV on the drive containing /boot; 9.) Added that PV back to the volume group; 10.) Resized the filesystems on the logical volumes on the volume group to shrink it to fit the new PV's space and resized the LV's accordingly (may require single-user mode to shrink some filesystems); 11.) Did a pvmove from the secondary drive back to the drive with /boot; 12.) Removed the secondary drive's PV from the VG (and removed the drive from the system). I was able to do this without a reboot step or going into single user mode since I had not allocated all of the space in the VG to LV's, so I was able to skip step 10. While the pvmoves were executing the system was fully up and running, but with degraded performance; no downtime was experienced until the maintenance window to do the version upgrade. Once step 12 completed, I was able to do the upgrade with no issues with /boot size and no loss of data on the volume group on the /boot drive. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On 6/24/2015 3:11 PM, Chuck Campbell wrote: Is there an easy to follow howto for normal LVM administration tasks. I get tired of googling every-time I have to do something I don't remember how to do regarding LVM, so I usually just don't bother with it at all. I believe it has some benefit for my use cases, but I've been reticent to use it, since the last time I got LVM problems, I lost everything on the volume, and had to restore from backups anyway. I suspect I shot myself in the foot, but I still don't know for sure. thanks, -chuck Gentoo Wiki has a pretty good cheat sheet on it: https://wiki.gentoo.org/wiki/LVM ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
At Thu, 25 Jun 2015 11:03:18 -0400 CentOS mailing list centos@centos.org wrote: On Wed, June 24, 2015 16:11, Chuck Campbell wrote: Is there an easy to follow howto for normal LVM administration tasks. I get tired of googling every-time I have to do something I don't remember how to do regarding LVM, so I usually just don't bother with it at all. I believe it has some benefit for my use cases, but I've been reticent to use it, since the last time I got LVM problems, I lost everything on the volume, and had to restore from backups anyway. I suspect I shot myself in the foot, but I still don't know for sure. At the risk of some ridicule I suggest that you look at installing Webmin. It is a web based system administration tool that I find invaluable. The two most common complaints I encounter when I discuss its merits are 'security' and 'transparency'. The security issue is trivially dealt with. Install Webmin and configure it to listen on 127.0.0.1 using its standard port TCP1. Install Firefox on the same host and then run firefox from an 'ssh -Y' session using the --noremote option. If you are totally paranoid then firewall TCP1 as well, configure Webmin to use https only, and then only start the webmin service when you are performing maintenance. There are less draconian measures that are in my opinion equally secure from a practical standpoint but I am sure that you can figure those out on your own. The transparency issue is really unanswerable. There exists a school of thought that if you are going to administer a Linux system (or OS of the proponent's choice) then you should learn the command syntax of every command that you are called upon to use. This is the one-and-only path to enlightenment. Like upholding motherhood and promoting the wholesomeness of apple-pie this sort of moralizing really brooks no answer. You can guess my opinion on that line of puritanism. HA! You only really need to learn *one* command: the man command. The man provides 'enlightenment' for all other commands: man vgdisplay man lvdisplay man lvcreate man lvextend man lvresize man lvreduce man lvremove man e2fsck man resize2fs These are the only LVM commands I use regularly (yes there a a pile more, but most are rarely used and a handful only used in startup/shutdown scripts or when rescuing) and I often end up use the man command to refresh my memory of the command options. As you have painfully discovered, infrequently used utilities and commands are difficult to deal with. The process of learning, or relearning, the correct arcana is particularly noisome given the notorious inconsistency of syntaxes across different utilities and the spotty coverage of up-to-date documentation. Google can be a dangerous guide given the wide variation of practice across differing flavours of *nix and the widespread aversion to providing dates on writings. In consequence I consign transparency arguments and their proponents to the religious fanatic file. Nothing personal but there is no point in arguing belief systems. Right, expecting a *web search* to give *correct* command documentation is problematical. Using the local system man pages often works better, since the man pages installed with the installed utilities will cover the *installed* version and not the version that might be installed on a *different* distro, etc. If you want to get infrequently performed sysadmin tasks done reliably and with a minimum of fuss use something like Webmin and get on with the rest of your life. -- Robert Heller -- 978-544-6933 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On Wed, June 24, 2015 16:11, Chuck Campbell wrote: Is there an easy to follow howto for normal LVM administration tasks. I get tired of googling every-time I have to do something I don't remember how to do regarding LVM, so I usually just don't bother with it at all. I believe it has some benefit for my use cases, but I've been reticent to use it, since the last time I got LVM problems, I lost everything on the volume, and had to restore from backups anyway. I suspect I shot myself in the foot, but I still don't know for sure. At the risk of some ridicule I suggest that you look at installing Webmin. It is a web based system administration tool that I find invaluable. The two most common complaints I encounter when I discuss its merits are 'security' and 'transparency'. The security issue is trivially dealt with. Install Webmin and configure it to listen on 127.0.0.1 using its standard port TCP1. Install Firefox on the same host and then run firefox from an 'ssh -Y' session using the --noremote option. If you are totally paranoid then firewall TCP1 as well, configure Webmin to use https only, and then only start the webmin service when you are performing maintenance. There are less draconian measures that are in my opinion equally secure from a practical standpoint but I am sure that you can figure those out on your own. The transparency issue is really unanswerable. There exists a school of thought that if you are going to administer a Linux system (or OS of the proponent's choice) then you should learn the command syntax of every command that you are called upon to use. This is the one-and-only path to enlightenment. Like upholding motherhood and promoting the wholesomeness of apple-pie this sort of moralizing really brooks no answer. You can guess my opinion on that line of puritanism. As you have painfully discovered, infrequently used utilities and commands are difficult to deal with. The process of learning, or relearning, the correct arcana is particularly noisome given the notorious inconsistency of syntaxes across different utilities and the spotty coverage of up-to-date documentation. Google can be a dangerous guide given the wide variation of practice across differing flavours of *nix and the widespread aversion to providing dates on writings. In consequence I consign transparency arguments and their proponents to the religious fanatic file. Nothing personal but there is no point in arguing belief systems. If you want to get infrequently performed sysadmin tasks done reliably and with a minimum of fuss use something like Webmin and get on with the rest of your life. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail James B. Byrnemailto:byrn...@harte-lyne.ca Harte Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
James B. Byrne wrote: On Wed, June 24, 2015 16:11, Chuck Campbell wrote: Is there an easy to follow howto for normal LVM administration tasks. I get tired of googling every-time I have to do something I don't remember how to do regarding LVM, so I usually just don't bother with it at all. I believe it has some benefit for my use cases, but I've been reticent to use it, since the last time I got LVM problems, I lost everything on the volume, and had to restore from backups anyway. I suspect I shot myself in the foot, but I still don't know for sure. At the risk of some ridicule I suggest that you look at installing Webmin. It is a web based system administration tool that I find invaluable. The two most common complaints I encounter when I discuss its merits are 'security' and 'transparency'. snip Back in '06 or '07, I installed webmin on the RHEL systems I was working on. It was a tremendous help installing and configuring openLDAP, whose tools, at least through '08, were very definitely *NOT* ready for prime time. Webmin let me beat it into submission. mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On 06/25/2015 11:03 AM, James B. Byrne wrote: On Wed, June 24, 2015 16:11, Chuck Campbell wrote: Is there an easy to follow howto for normal LVM administration tasks. I get tired of googling every-time I have to do something I don't remember how to do regarding LVM, so I usually just don't bother with it at all. I believe it has some benefit for my use cases, but I've been reticent to use it, since the last time I got LVM problems, I lost everything on the volume, and had to restore from backups anyway. I suspect I shot myself in the foot, but I still don't know for sure. At the risk of some ridicule I suggest that you look at installing Webmin. It is a web based system administration tool that I find invaluable. The two most common complaints I encounter when I discuss its merits are 'security' and 'transparency'. The security issue is trivially dealt with. Install Webmin and configure it to listen on 127.0.0.1 using its standard port TCP1. Install Firefox on the same host and then run firefox from an 'ssh -Y' session using the --noremote option. If you are totally paranoid then firewall TCP1 as well, configure Webmin to use https only, and then only start the webmin service when you are performing maintenance. There are less draconian measures that are in my opinion equally secure from a practical standpoint but I am sure that you can figure those out on your own. The transparency issue is really unanswerable. There exists a school of thought that if you are going to administer a Linux system (or OS of the proponent's choice) then you should learn the command syntax of every command that you are called upon to use. This is the one-and-only path to enlightenment. Like upholding motherhood and promoting the wholesomeness of apple-pie this sort of moralizing really brooks no answer. You can guess my opinion on that line of puritanism. As you have painfully discovered, infrequently used utilities and commands are difficult to deal with. The process of learning, or relearning, the correct arcana is particularly noisome given the notorious inconsistency of syntaxes across different utilities and the spotty coverage of up-to-date documentation. Google can be a dangerous guide given the wide variation of practice across differing flavours of *nix and the widespread aversion to providing dates on writings. In consequence I consign transparency arguments and their proponents to the religious fanatic file. Nothing personal but there is no point in arguing belief systems. If you want to get infrequently performed sysadmin tasks done reliably and with a minimum of fuss use something like Webmin and get on with the rest of your life. That is fine until suddenly you find yourself without your crutch. -- Stephen Clark *NetWolves Managed Services, LLC.* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On Tue, 2015-06-23 at 11:15 -0500, Jason Warr wrote: On 6/23/2015 10:33 AM, Marko Vojinovic wrote: Inside / (which is mostly always ext4), 100% of the time. :-) That said, I prefer virtual machines over multiboot environments, and I absolutely despise LVM --- that cursed thing is never getting on my drives. Never again, that is... I'm curious what has made some people hate LVM so much. Having to read the documentation? That has always been what I assumed - people want to do something without being bothered with understanding what they are doing. I have been using it for years on ... Yep. Use it on every server, no exceptions, never had issues I did not cause myself - and moving storage around, adding storage, all on running servers... never a problem. -- Adam Tauno Williams mailto:awill...@whitemice.org GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
Robert Heller wrote: At Thu, 25 Jun 2015 11:03:18 -0400 CentOS mailing list centos@centos.org wrote: On Wed, June 24, 2015 16:11, Chuck Campbell wrote: Is there an easy to follow howto for normal LVM administration tasks. I get tired of googling every-time I have to do something I don't remember how to do regarding LVM, so I usually just don't bother with it at all. I believe it has some benefit for my use cases, but I've been reticent to use it, since the last time I got LVM problems, I lost everything on the volume, and had to restore from backups anyway. I suspect I shot myself in the foot, but I still don't know for sure. At the risk of some ridicule I suggest that you look at installing Webmin. It is a web based system administration tool that I find invaluable. The two most common complaints I encounter when I discuss its merits are 'security' and 'transparency'. snip HA! You only really need to learn *one* command: the man command. The man provides 'enlightenment' for all other commands: man vgdisplay man lvdisplay man lvcreate man lvextend man lvresize man lvreduce man lvremove man e2fsck man resize2fs snip You missed one: man man. mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
Once upon a time, Adam Tauno Williams awill...@whitemice.org said: There may be numerous commands... but isn't it pretty obvious what each one of them do? Often lvtabtab is plenty of hinting to get to the right thing. And each of the commands uses the same syntax for options. The key thing is to know the LVM architecture. Once you have a basic grasp of that, the rest is usually pretty easy to figure out. At the bottom, you have some block device. This is most often a standard disk partition (e.g. /dev/sda2); in some cases, it may be a whole disk (e.g. /dev/sdb). The first layer of LVM is the physical volume (PV). This is basically importing a block device into the LVM stack; the PV uses the name of the underlying block device (so still /dev/sda2 or /dev/sdb). You put one or more PVs into a volume group (VG), and give it a name (e.g. vg_myhost, but there's nothing special about putting vg_ at the front, that's just something some people do). This is where the functionality and flexibility starts to come into play. A VG can have multiple PVs and spread data across them, do RAID, move blocks from one PV to another, etc. You then divide up a VG into logical volumes (LVs), also giving them names (e.g. lv_root; again, lv_ is just a common naming scheme, not a requirement). This is where you can do snapshots, thin provisioning, etc. At that point, you'll have a new block device, like /dev/vg_myhost/lv_root, and you can make filesystems, assign to VMs, set up swap, etc. The commands at each layer of LVM follow a similar scheme, so there's pvcreate, vgcreate, and lvcreate for example. The arguments also follow a common scheme. For the regular admin stuff, you can typically figure out with a --help what you need (using the man page as a refresher or extended reference). It's basically a way to assemble one arbitrary set of block devices and then divide them into another arbitrary set of block devices, but now separate from the underlying physical structure. Regular partitions have various limitations (one big one on Linux being that modifying the partition table of a disk with in-use partitions is a PITA and most often requires a reboot), and LVM abstracts away some of them. LVM is a set of commands and modules layered on top of the Linux kernel's device mapper system. DM is just a way to map block A of virtual device X to block B of physical device Y; at one point, there was some discussion of kicking partition handling out of the kernel and just going with DM for everything (requires some form of init ramdisk though which complicates some setups). -- Chris Adams li...@cmadams.net ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On Thu, 2015-06-25 at 11:50 -0400, Robert Heller wrote: At Thu, 25 Jun 2015 11:03:18 -0400 CentOS mailing list centos@centos.org wrote:HA! You only really need to learn *one* command: the man command. The man provides 'enlightenment' for all other commands: man vgdisplay man lvdisplay man lvcreate man lvextend man lvresize man lvreduce man lvremove man e2fsck man resize2fs These are the only LVM commands I use regularly (yes there a a pile more, but most are rarely used and a handful only used in startup/shutdown scripts or when rescuing) There may be numerous commands... but isn't it pretty obvious what each one of them do? Often lvtabtab is plenty of hinting to get to the right thing. And each of the commands uses the same syntax for options. spotty coverage of up-to-date documentation. Google can be a dangerous guide given the wide variation of practice across differing.. Yes, exactly. DO NOT USE GOOGLE - USE THE ^@$^* DOCUMENTATION! Right, expecting a *web search* to give *correct* command documentation is problematical. Using the local system man pages often works better, since the man pages installed with the installed utilities will cover the *installed* version and not the version that might be installed on a *different* +1 If you want to get infrequently performed sysadmin tasks done reliably and with a minimum of fuss use something like Webmin and get on with the rest of your life. And take notes! You are sitting at a computer after all. -- Adam Tauno Williams mailto:awill...@whitemice.org GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On Thu, Jun 25, 2015 at 10:49:57AM -0500, Jason Warr wrote: On 6/24/2015 3:11 PM, Chuck Campbell wrote: Is there an easy to follow howto for normal LVM administration tasks. I get tired of googling every-time I have to do something I don't remember how to do regarding LVM, so I usually just don't bother with it at all. I believe it has some benefit for my use cases, but I've been reticent to use it, since the last time I got LVM problems, I lost everything on the volume, and had to restore from backups anyway. I suspect I shot myself in the foot, but I still don't know for sure. thanks, -chuck Gentoo Wiki has a pretty good cheat sheet on it: https://wiki.gentoo.org/wiki/LVM I have my own page, limited and out of date but.. http://srobb.net/lvm.html -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On Thu, June 25, 2015 11:59 am, Scott Robbins wrote: On Thu, Jun 25, 2015 at 10:49:57AM -0500, Jason Warr wrote: On 6/24/2015 3:11 PM, Chuck Campbell wrote: Is there an easy to follow howto for normal LVM administration tasks. I get tired of googling every-time I have to do something I don't remember how to do regarding LVM, so I usually just don't bother with it at all. I believe it has some benefit for my use cases, but I've been reticent to use it, since the last time I got LVM problems, I lost everything on the volume, and had to restore from backups anyway. I suspect I shot myself in the foot, but I still don't know for sure. thanks, -chuck Gentoo Wiki has a pretty good cheat sheet on it: https://wiki.gentoo.org/wiki/LVM I have my own page, limited and out of date but.. http://srobb.net/lvm.html AFAIK, your page exists forever. This is how I first learned LVM: from your page. (Not that I use LVM much, but whenever I need to do something LVM, I'm confident I can - using your webpage). Thanks a lot!! Valeri -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On 6/25/2015 8:50 AM, Robert Heller wrote: man vgdisplay man lvdisplay man lvcreate man lvextend man lvresize man lvreduce man lvremove man e2fsck man resize2fs man xfs_growfs -- john r pierce, recycling bits in santa cruz ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
At Thu, 25 Jun 2015 13:18:04 -0400 CentOS mailing list centos@centos.org wrote: Robert Heller wrote: At Thu, 25 Jun 2015 11:03:18 -0400 CentOS mailing list centos@centos.org wrote: On Wed, June 24, 2015 16:11, Chuck Campbell wrote: Is there an easy to follow howto for normal LVM administration tasks. I get tired of googling every-time I have to do something I don't remember how to do regarding LVM, so I usually just don't bother with it at all. I believe it has some benefit for my use cases, but I've been reticent to use it, since the last time I got LVM problems, I lost everything on the volume, and had to restore from backups anyway. I suspect I shot myself in the foot, but I still don't know for sure. At the risk of some ridicule I suggest that you look at installing Webmin. It is a web based system administration tool that I find invaluable. The two most common complaints I encounter when I discuss its merits are 'security' and 'transparency'. snip HA! You only really need to learn *one* command: the man command. The man provides 'enlightenment' for all other commands: man vgdisplay man lvdisplay man lvcreate man lvextend man lvresize man lvreduce man lvremove man e2fsck man resize2fs snip You missed one: man man. It is 'presumed' that one has learned the man command itself and never ever need to do a 'man man' :-). From there all other knowledge flows... mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos -- Robert Heller -- 978-544-6933 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
John R Pierce wrote: On 6/25/2015 11:12 AM, James A. Peltier wrote: You forgot man this opinion thread is getting really long No manual entry for this opinion thread is getting really long That's obviously not the case: it's *all* manual entry of text g mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
- Original Message - | On 6/25/2015 8:50 AM, Robert Heller wrote: | man vgdisplay | man lvdisplay | man lvcreate | man lvextend | man lvresize | man lvreduce | man lvremove | man e2fsck | man resize2fs | | man xfs_growfs You forgot man this opinion thread is getting really long -- James A. Peltier IT Services - Research Computing Group Simon Fraser University - Burnaby Campus Phone : 604-365-6432 Fax : 778-782-3045 E-Mail : jpelt...@sfu.ca Website : http://www.sfu.ca/itservices Twitter : @sfu_rcg Powering Engagement Through Technology ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On Thu, Jun 25, 2015 at 12:05:13PM -0500, Valeri Galtsev wrote: On Thu, June 25, 2015 11:59 am, Scott Robbins wrote: On Thu, Jun 25, 2015 at 10:49:57AM -0500, Jason Warr wrote: AFAIK, your page exists forever. This is how I first learned LVM: from your page. (Not that I use LVM much, but whenever I need to do something LVM, I'm confident I can - using your webpage). Thanks a lot!! And thank you for the kind words. It's always good to hear that these things benefit someone. -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On Thu, June 25, 2015 12:18 pm, m.r...@5-cent.us wrote: Robert Heller wrote: At Thu, 25 Jun 2015 11:03:18 -0400 CentOS mailing list centos@centos.org wrote: On Wed, June 24, 2015 16:11, Chuck Campbell wrote: Is there an easy to follow howto for normal LVM administration tasks. I get tired of googling every-time I have to do something I don't remember how to do regarding LVM, so I usually just don't bother with it at all. I believe it has some benefit for my use cases, but I've been reticent to use it, since the last time I got LVM problems, I lost everything on the volume, and had to restore from backups anyway. I suspect I shot myself in the foot, but I still don't know for sure. At the risk of some ridicule I suggest that you look at installing Webmin. It is a web based system administration tool that I find invaluable. The two most common complaints I encounter when I discuss its merits are 'security' and 'transparency'. snip HA! You only really need to learn *one* command: the man command. The man provides 'enlightenment' for all other commands: man vgdisplay man lvdisplay man lvcreate man lvextend man lvresize man lvreduce man lvremove man e2fsck man resize2fs snip You missed one: man man. Cool! this makes my day! It is just itching to add two more: man info info man Valeri Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On 6/25/2015 11:12 AM, James A. Peltier wrote: You forgot man this opinion thread is getting really long No manual entry for this opinion thread is getting really long -- john r pierce, recycling bits in santa cruz ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] LVM hatred, was Re: /boot on a separate partition?
Gordon Messmer gordon.messmer at gmail.com Wed Jun 24 01:42:13 UTC 2015 I wondered the same thing, especially in the context of someone who prefers virtual machines. LV-backed VMs have *dramatically* better disk performance than file-backed VMs. I did a bunch of testing of Raw, qcow2, and LV backed VM storage circa Fedora 19/20 and found very little difference. What mattered most was the (libvirt) cache setting, accessible by virsh edit the xml config or virt-manager through the GUI. There have been a lot of optimizations in libvirt and qemu that make qcow2 files perform comparable to LVs. For migrating VMs, it's easier if they're a file. And qcow2 snapshots are more practical than LVM (thick) snapshots. The thin snapshots are quite good though they take a lot of familiarity with setting them up. -- Chris Murphy ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] LVM hatred, was Re: /boot on a separate partition?
Mike - st257 silvertip257 at gmail.com Tue Jun 23 16:40:47 UTC 2015 On Tue, Jun 23, 2015 at 12:15 PM, Jason Warr jason at warr.net wrote: I'm curious what has made some people hate LVM so much. I have been using it for years on thousands of No clue. My experiences with LVM have been positive as well. And in opinion it doesn't add much complexity (if you know the LVM tools, you're fine). Flexibility is worth an ounce of complexity. I think LVM is badass, however if you don't know the LVM tools, you're instantly tossed deep into the weeds. Most every letter, lower and upper case, seems to be used twice by each of the lvm commands. I don't have enough fingers to count the number of lvm commands. There's so much intricate detail required for creating LVM layouts and doing snapshots and snapshot deletion compared to Btrfs that I've just about given up on LVM. I've also never had Btrfs snapshots explode on me like LVM thinp snapshots have when the metadata pool wasn't made big enough in advance (and it isn't made big enough by default, apparently). Most any typical maneuver done on LVM can be done much more easily and intuitively with Btrfs. So these days I just focus on Btrfs even though I definitely don't hate LVM. On desktop Linux, making LVM the default layout I think is a bad decision. It causes mortal users more trouble than it's worth. I'd be a bit more accommodating if LVM had integrated encryption with live bi-directional conversion. -- Chris Murphy ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] LVM hatred, was Re: /boot on a separate partition?
Chris Adams linux at cmadams.net Wed Jun 24 19:06:19 UTC 2015 Btrfs may eventually obsolete a lot of uses of LVM, but that's down the road. LVM is the emacs of storage. It'll be here forever. Btrfs doesn't export (virtual) block devices like LVM can, so it can't be a backing for say iSCSI. And it's also at the moment rather catatonic when it comes to VM images. This is mitigated if you set xattr +C at image create time (it must be zero length file for +C to take). But if you cp --reflink or snapshot the containing subvolume, then COW starts to happen for new writes to either copy; overwrites to either copies newly written blocks are nocow. So anyway you can quickly get into complicated states with VM images on Btrfs. I'm not sure of the long term plan. This is how to set xattr +C at qcow2 create time, only applicable when the qcow2 is on Btrfs. # qemu-img create -o nocow=on But really piles more testing is needed to better understand some things with Btrfs and VMs. It's all quite complicated what's going on with these layers. Even though my VM images get monstrous numbers of fragments if I don't use +C, I haven't yet seen a big performance penalty as a result when the host and guest are using Btrfs and the cache is set to unsafe. Now, you might say, that's crazy! It's called unsafe for a reason! Yes, but I've also viscously killed the VM while writes were happening and at most I lose a bit of data that was in flight, the guest fs is not corrupt at all, not even any complaints on the remount. I've got limited testing killing the host while the writes are happening, and there is more data loss due to delayed allocation probably, but again the host and guest Btrfs are fine - no mount complaints at all. And you kinda hope the host isn't often dying... NTFS in qcow2 on Btrfs without +C however? From Btrfs list anecdote this combination appears to cause hundreds of thousands of fragments in short order, and serious performance penalties. But I haven't tested this. I'm guessing something about NTFS journalling and flushing, and suboptimal cache setting for libvirt is probably causing too aggressive flushes to disk and each flush is a separate extent. Just a guess. -- Chris Murphy ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] LVM hatred, was Re: /boot on a separate partition?
Chris Adams linux at cmadams.net Wed Jun 24 13:14:34 UTC 2015 There are plenty of people that have documented the performance differences, just Google it. This is consistent with what I've experienced. Minimal difference. http://web-docs.gsi.de/~tstibor/iozone/qcow.vs.lvm/ -- Chris Murphy ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
At Wed, 24 Jun 2015 14:06:30 -0400 CentOS mailing list centos@centos.org wrote: Gordon Messmer wrote: On 06/23/2015 08:10 PM, Marko Vojinovic wrote: Ok, you made me curious. Just how dramatic can it be? From where I'm sitting, a read/write to a disk takes the amount of time it takes, the hardware has a certain physical speed, regardless of the presence of LVM. What am I missing? Well, there's best and worst case scenarios. Best case for file-backed VMs is pre-allocated files. It takes up more space, and takes a while to set up initially, but it skips block allocation and probably some fragmentation performance hits later. Worst case, though, is sparse files. In such a setup, when you write a new file in a guest, the kernel writes the metadata to the journal, then MVNCH Here's a question: all of the arguments you're giving have to do with VMs. Do you have some for straight-on-the-server, non-VM cases? In the most *common* case the straight-on-the-server, non-VM case are the VM themselves. Basically, in the vast number of servers you most commonly have a host with a number of VMs. The VMs are the publicly visible servers and the host is pretty much invisible. The VMs themselves won't be using LVM, but the host server will be. Otherwise... I recently upgraded to a newer laptop and put a 128G SSD disk in it. My previous laptop had a 60gig IDE disk. Since I didn't have any need for more files (at this time!) I set the laptop with LVM. Because of how I do backups and because of the kinds of things I have on my laptop, I have multiple logical volumes: newgollum.deepsoft.com% df -h FilesystemSize Used Avail Use% Mounted on /dev/mapper/vg_newgollum-lv_root 9.8G 5.7G 3.6G 62% / tmpfs 1.9G 8.2M 1.9G 1% /dev/shm /dev/sda1 477M 86M 367M 19% /boot /dev/mapper/vg_newgollum-lv_home 4.8G 4.0G 602M 88% /home /dev/mapper/vg_newgollum-scratch 30G 10G 18G 36% /scratch /dev/mapper/vg_newgollum-mp3s 9.8G 5.1G 4.2G 55% /mp3s I only have about 60gig presently allocated (there is about 60gig 'free'). And yes, this is a laptop with a single physical disk. Some day I might create additional LVs and/or grow the existing LVs. I *might* even install a VM or two on this laptop. My disktop machine is also a host to a number of VMs (mostly used for build environments for different versions / flavors of Linux). Here LVM is pretty much a requirement, esp. since its disks are RAID'ed. I also manage a server for the local public library. The host runs CentOS 6 on the bare metal. It also provides DHCP, DNS, Firewall, and IP routing. The library's workstations (for staff and patrons) are diskless and boot using tftp, but they actually run Ubuntu 14.04 (since it is more 'user friendly'), so I have a Ubuntu 14.04 (server) VM providing tftp boot for Ubuntu 14.04's kernel and NFS for Ubuntu 14.04's root and /usr file systems. (The CentOS host provides the /home file system.) And just as an extra 'benefit' (?) I have a VM running a 32-bit version of MS-Windows 8 (this is needed to talk to the library's heating system). This is a basic server, but uses virtualization for selected services. Except for 'appliance' servers, I see things being more and more common that pure 'bare metal' servers becoming the exception rather than the rule. For all sorts of reasons (including security), servers will commonly be using virtualization for many purposes. And LVM makes things really easy to deal with disk space for VMs. mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos -- Robert Heller -- 978-544-6933 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On Wed, 24 Jun 2015 10:40:59 -0700 Gordon Messmer gordon.mess...@gmail.com wrote: On 06/23/2015 08:10 PM, Marko Vojinovic wrote: For concreteness, let's say I have a guest machine, with a dedicated physical partition for it, on a single drive. Or, I have the same thing, only the dedicated partition is inside LVM. Why is there a performance difference, and how dramatic is it? Well, I said that there's a big performance hit to file-backed guests, not partition backed guests. You should see exactly the same disk performance on partition backed guests as LV backed guests. Oh, I see, I missed the detail about the guest being file-backed when I read your previous reply. Of course, I'm fully familiar with the drawbacks of file-backed virtual drives, as opposed to physical (or LVM) partitions. I was (mistakenly) under the impression that you were talking about the performance difference between a bare partition and a LVM partition that the guest lives on. However, partitions have other penalties relative to LVM. Ok, so basically what you're saying is that in the usecase when one is spinning VM's on a daily basis, LVM is more flexible than dedicating hardware partitions for each new VM. I can understand that. Although, I could guess that if one is spinning VM's on a daily basis, their performance probably isn't an issue, so that a file-backed VM would do the job... It depends on what you use them for, in the end. It's true I never came across such a scenario. In my experience so far, spinning a new VM is a rare process, which includes planning, designing, estimating resource usage, etc... And then, once the VM is put in place, it is intended to work long-term (usually until its OS reaches EOL or the hardware breaks). But I get your point, with LVM you have additional flexibility to spin test-VM's basically every day if you need to, keeping the benefit of performance level of partition-backed virtual drives. Ok, you have me convinced! :-) Next time I get my hands on a new harddrive, I'll put LVM on it, and see if it helps me manage VM's more efficiently. Doing this on a single drive doesn't run the risk of losing more than one drive's worth of data if it fails, so I'll play with it a little more in the context of VM's, and we'll see if it improves my workflow. Maybe I'll have a change of heart over LVM after all. ;-) Best, :-) Marko ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
At Wed, 24 Jun 2015 04:10:35 +0100 CentOS mailing list centos@centos.org wrote: On Tue, 23 Jun 2015 18:42:13 -0700 Gordon Messmer gordon.mess...@gmail.com wrote: I wondered the same thing, especially in the context of someone who prefers virtual machines. LV-backed VMs have *dramatically* better disk performance than file-backed VMs. Ok, you made me curious. Just how dramatic can it be? From where I'm sitting, a read/write to a disk takes the amount of time it takes, the hardware has a certain physical speed, regardless of the presence of LVM. What am I missing? For concreteness, let's say I have a guest machine, with a dedicated physical partition for it, on a single drive. Or, I have the same thing, only the dedicated partition is inside LVM. Why is there a performance difference, and how dramatic is it? If you convince me, I might just change my opinion about LVM. :-) Well if you are comparing direct partitions to LVM there is no real difference. OTOH, if you have more than a few VMs (eg more than the limits imposed by the partitioning system) and/or want to create [temporary] ones 'on-the-fly', using LVM makes that trivially possible. Otherwise, you have to repartition the disk and reboot the host. This puts you 'back' in the old-school reality of a multi-boot system. And partitioning a RAID array is tricky and combersome. Resizing physical partitions is also non-trivial. Bascally, LVM gives you on-the-fly 'partitioning', without rebooting. It is just not possible (AFAIK) to always update partition tables of a running system (never if the disk is the system disk). Most partitioning tools are not really designed for dynamic re-sizing of partitions and it is a highly error-prone process. Most partitioning tools are designed for dealing with a 'virgin' disk (or a re-virgined disk) with the idea that the partitioning won't be revisited once the O/S has been installed. LVM is all about creating and managing *dynamic* 'partitions' (which is what Logical Volumes effectively are). And no, there is little advantage in using multiple PVs. To get performance gains (and/or redundency, etc.), one uses real RAID (eg kernel software RAID -- md or hardware RAID), then layers LVM on top of that. The 'other' *alternitive* is to use virtual container disks (eg image files as disks), which have horrible performance (compared to LVM or hard partitions) and are hard to backup. The *additional* feature: with LVM you can take a snapshot of the VM's disk and back it up safely. Otherwise you *have* to shutdown the VM and remount the VM's disk to back it up OR you have to install backup software (eg amanda-client or the like) on the VM and back it up over the virtual network. It some cases (many cases!) it is not possible to either shutdown the VM and/or install backup software on it (eg the VM is running a 'foreign' or otherwise imcompatible O/S). Oh, and just please don't tell me that the load can be spread accross two or more harddrives, cutting the file access by a factor of two (or more). I can do that with raid, no need for LVM. Stick to a single harddrive scenario, please. Best, :-) Marko ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos -- Robert Heller -- 978-544-6933 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
Once upon a time, Marko Vojinovic vvma...@gmail.com said: On Tue, 23 Jun 2015 18:42:13 -0700 Gordon Messmer gordon.mess...@gmail.com wrote: I wondered the same thing, especially in the context of someone who prefers virtual machines. LV-backed VMs have *dramatically* better disk performance than file-backed VMs. Ok, you made me curious. Just how dramatic can it be? From where I'm sitting, a read/write to a disk takes the amount of time it takes, the hardware has a certain physical speed, regardless of the presence of LVM. What am I missing? File-backed images have to go through the filesystem layer. They are not allocated contiguously, so what appear to be sequential reads inside the VM can be widely scattered across the underlying disk. There are plenty of people that have documented the performance differences, just Google it. -- Chris Adams li...@cmadams.net ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On Tue, 23 Jun 2015, John R Pierce wrote: While it has the same concepts, physical volumes, volume groups, logical volumes, the LVM in AIX shares only the initials with Linux. I've heard that Linux's LVM was based on HP-UX's design. Sure, and IRIX had a similar concept, although my experiences with that were slightly less good than with LVM on linux. in AIX, the LVM is tightly integrated with file system management, so you issue the command to grow a file system, and it automatically grows the underlying logical volume. the OS itself can automatically grow file systems when its installing software. Also, in AIX, the volume manager is the raid manager, you say 'copies = 2' as an attribute of a LV, and data is mirrored. Without knowing the details, this is possibly just semantics. With lvresize, you can resize the LV and the filesystem in one go. With lvcreate --type raid1 you can specify that a given LV is RAID1 mirrored. jh ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On 06/23/2015 09:00 PM, Marko Vojinovic wrote: On Tue, 23 Jun 2015 19:08:24 -0700 Gordon Messmer gordon.mess...@gmail.com wrote: 1) LVM makes MBR and GPT systems more consistent with each other, reducing the probability of a bug that affects only one. 2) LVM also makes RAID and non-RAID systems more consistent with each other, reducing the probability of a bug that affects only one. OTOH, it increases the probability of a bug that affects LVM itself. No, it doesn't. As Anaconda supports more types of disk and filesystem configuration, its complexity increases, which increases the probability that there are bugs. The number of users is not affected by complexity growth, but the permutations of possible configurations grows. Therefore, the number of users of some configurations is smaller, which means that there are fewer people testing the edge cases, and bugs that affect those edge cases are likely to last longer. Consistency reduces the probability of bugs. But really, these arguments sound like a strawman. It reduces the probability of a bug that affects one of the setups --- I have a hard time imagining a real-world usecase where something like that can be even observable, let alone relevant. Follow anaconda development if you need further proof. 3) MBR has silly limits on the number of partitions, that don't affect LVM. Sure, GPT is better, but so long as both are supported, the best solution is the one that works in both cases. That only makes sense if I need a lot of partitions on a system that doesn't support GPT. You are looking at this from the perspective of you, one user. I am looking at this from the perspective of the developers who manage anaconda, and ultimately have to support all of the users. That is, you are considering an anecdote, and missing the bigger picture. LVM is an inexpensive abstraction from the specifics of disk partitions. It is more flexible than working without it. It is consistent across MBR, GPT, and RAID volumes underlying the volume group, which typically means fewer bugs. 4) There are lots of situations where you might want to expand a disk/filesystem on a server or virtual machine. Desktops might do so less often, but there's no specific reason to put more engineering effort into making the two different. The best solution is the one that works in both cases. What do you mean by engineering effort? When I'm setting up a data storage farm, I'll use LVM. When I'm setting up my laptop, I won't. What effort is there? The effort on the part of the anaconda and dracut developers who have to test and support various disk configurations. The more consistent systems are, the fewer bugs we hit. I just see it as an annoyance of having to customize my partition layout on the laptop, during the OS installation (customizing a storage farm setup is pretty mandatory either way, so it doesn't make a big difference). In my case, I set up all of my systems with kickstart and they all have the same disk configuration except for RAID. Every disk in every system has a 200MB partition, a 1G partition, and then a partition that fills the rest of the disk. On laptops, that's the EFI partition, /boot, and a PV for LVM. On a BIOS system, it's a bios_grub partition, /boot, and a PV for LVM. On a server, the second and third are RAID1 or RAID10 members for sets that are /boot and a PV for LVM. Because they all have exactly the same partition set, when I replace a disk in a server, a script sets up the partitions and adds them to the RAID sets. With less opportunity for human error, my system is more reliable, it can be managed by less experienced members of my team, and management takes less time. When you manage hundreds of systems, you start to see the value of consistency. And you can't get to the point of managing thousands without it. 5) Snapshots are the only practical way to get consistent backups, and you should be using them. That depends on what kind of data you're backing up. If you're backing up the whole filesystem, than I agree. But if you are backing up only certain critical data, I'd say that a targeted rsync can be waaay more efficient. You can use a targeted rsync from data that's been snapshotted, so that's not a valid criticism. And either way, if you aren't taking snapshots, you aren't guaranteed consistent data. If you rsync a file that's actively being written, the destination file may be corrupt. The only guarantee of consistent backups is to quiesce writes, take a snapshot, and back up from the snapshot volume. LVM has virtually zero cost, so there's no practical benefit to not using it. If you need it. If you don't need it, there is no practical benefit of having it, either. It's just another potential point of failure, waiting to happen. The *cost* the same whether you need it or not. The value changes, but the cost is the same. Cost and value are different things. LVM
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
Gordon Messmer wrote: On 06/23/2015 08:10 PM, Marko Vojinovic wrote: Ok, you made me curious. Just how dramatic can it be? From where I'm sitting, a read/write to a disk takes the amount of time it takes, the hardware has a certain physical speed, regardless of the presence of LVM. What am I missing? Well, there's best and worst case scenarios. Best case for file-backed VMs is pre-allocated files. It takes up more space, and takes a while to set up initially, but it skips block allocation and probably some fragmentation performance hits later. Worst case, though, is sparse files. In such a setup, when you write a new file in a guest, the kernel writes the metadata to the journal, then MVNCH Here's a question: all of the arguments you're giving have to do with VMs. Do you have some for straight-on-the-server, non-VM cases? mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On 06/24/2015 11:06 AM, m.r...@5-cent.us wrote: Here's a question: all of the arguments you're giving have to do with VMs. Do you have some for straight-on-the-server, non-VM cases? Marko sent two messages and suggested that we keep the VM performance question as a reply to that one. My reply to his other message is not specific to VMs. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On 06/23/2015 08:10 PM, Marko Vojinovic wrote: Ok, you made me curious. Just how dramatic can it be? From where I'm sitting, a read/write to a disk takes the amount of time it takes, the hardware has a certain physical speed, regardless of the presence of LVM. What am I missing? Well, there's best and worst case scenarios. Best case for file-backed VMs is pre-allocated files. It takes up more space, and takes a while to set up initially, but it skips block allocation and probably some fragmentation performance hits later. Worst case, though, is sparse files. In such a setup, when you write a new file in a guest, the kernel writes the metadata to the journal, then writes the file's data block, then flushes the journal to the filesystem. Every one of those writes goes through the host filesystem layer, often allocating new blocks, which goes through the host's filesystem journal. If each of those three writes hit blocks not previously used, then the host may do three writes for each of them. In that case, one write() in an application in a VM becomes nine disk writes in the VM host. The first time I benchmarked a sparse-file-backed guest vs an LVM backed guest, bonnie++ measured block write bandwidth at about 12.5% (1/8) native disk write performance. Yesterday I moved a bunch of VMs from a file-backed virt server (set up by someone else) to one that used logical volumes. Block write speed on the old server, measured with bonnie++, was about 21.6MB/s in the guest and about 39MB/s on the host. So, less bad than a few years prior, but still bad. (And yes, all of those numbers are bad. It's a 3ware controller, what do you expect?) LVM backed guests measure very nearly the same as bare metal performance. After migration, bonnie++ reports about 180MB/s block write speed. For concreteness, let's say I have a guest machine, with a dedicated physical partition for it, on a single drive. Or, I have the same thing, only the dedicated partition is inside LVM. Why is there a performance difference, and how dramatic is it? Well, I said that there's a big performance hit to file-backed guests, not partition backed guests. You should see exactly the same disk performance on partition backed guests as LV backed guests. However, partitions have other penalties relative to LVM. 1) If you have a system with a single disk, you have to reboot to add partitions for new guests. Linux won't refresh the partition table on the disk it boots from. 2) If you have two disks you can allocate new partitions on the second disk without a reboot. However, your partition has to be contiguous, which may be a problem, especially over time if you allocate VMs of different sizes. 3) If you want redundancy, partitions on top of RAID is more complex than LVM on top of RAID. As far as I know, partitions on top of RAID are subject to the same limitation as in #1. 4) As far as I know, Anaconda can't set up a logical volume that's a redundant type, so LVM on top of RAID is the only practical way to support redundant storage of your host filesystems. If you use LVM, you don't have to remember any oddball rules. You don't have to reboot to set up new VMs when you have one disk. You don't have to manage partition fragmentation. Every system, whether it's one disk or a RAID set behaves the same way. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On 06/24/2015 12:06 PM, Chris Adams wrote: LVM snapshots make it easy to get point-in-time consistent backups, including databases. For example, with MySQL, you can freeze and flush all the databases, snapshot the LV, and release the freeze. Exactly. And I mention this from time to time... I'm working on infrastructure to make that more common and more consistent: https://bitbucket.org/gordonmessmer/dragonsdawn-snapshot If you're interested in testing or development (or even advocacy), I'd love to have more people contributing. That also avoids the access-time churn (for backup programs that don't know O_NOATIME, like any that use rsync). Yes, though rsync based systems are usually always-incremental, so they won't access files that haven't been modified, and impact on atime is minimal after the first backup. That's server stuff. On a desktop with a combination of SSD and spinning rust drives, LVM can give you transparent SSD caching of hot data (rather than you having to put some filesystems on SSD and some on hard drive). Interesting. I wasn't aware that LVM had that option. I've been looking at bcache and dm-cache. I'll have to look into that as well. Now, if btrfs ever gets all the kinks worked out (and has a stable fsck for the corner cases), it integrates volume management into the filesystem, which makes some of the management easier. btrfs and zfs are also more reliable than RAID. If a bit flips in a RAID set, all that can be determined is that the blocks are not consistent. There's no information about which blocks are correct, or how to repair the inconsistency. btrfs and zfs *do* have that information, so they can repair those errors correctly. As much as I like LVM today, I look forward to ditching RAID and LVM in favor of btrfs. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On 06/24/2015 12:35 PM, Gordon Messmer wrote: Interesting. I wasn't aware that LVM had that option. I've been looking at bcache and dm-cache. I'll have to look into that as well. heh. LVM cache *is* dm-cache. Don't I feel silly. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On 6/24/2015 2:06 PM, Chris Adams wrote: Once upon a time, m.r...@5-cent.us m.r...@5-cent.us said: Here's a question: all of the arguments you're giving have to do with VMs. Do you have some for straight-on-the-server, non-VM cases? I've used LVM on servers with hot-swap drives to migrate to new storage without downtime a number of times. Add new drives to the system, configure RAID (software or hardware), pvcreate, vgextend, pvmove, vgreduce, and pvremove (and maybe a lvextend and resize2fs/xfs_growfs). Never unmounted a filesystem, just some extra disk I/O. Even in cases where I had to shutdown or reboot a server to get drives added, moving data could take a long downtime, but with LVM I can live-migrate from place to place. This is one of my primary use cases, and a real big time saver. I do this allot when migrating Oracle DB LUN's to larger sized, new allocations. It works great weather you are using ASM or any Linux filesystem. It is especially handy when migrating from one SAN frame to another. You can fully migrate with zero down time if you do even a small amount of planning ahead. There are just so many time saving things you can do with it. Sure, if all groups in the chain plan ahead properly there can be very little change needed but how often does that happen in real life? It is part of my job to plan well enough ahead to know that storage needs grow despite everyone's best intentions to get out of the gate properly. LVM makes growing much easier and flexible. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
Once upon a time, m.r...@5-cent.us m.r...@5-cent.us said: Here's a question: all of the arguments you're giving have to do with VMs. Do you have some for straight-on-the-server, non-VM cases? I've used LVM on servers with hot-swap drives to migrate to new storage without downtime a number of times. Add new drives to the system, configure RAID (software or hardware), pvcreate, vgextend, pvmove, vgreduce, and pvremove (and maybe a lvextend and resize2fs/xfs_growfs). Never unmounted a filesystem, just some extra disk I/O. Even in cases where I had to shutdown or reboot a server to get drives added, moving data could take a long downtime, but with LVM I can live-migrate from place to place. LVM snapshots make it easy to get point-in-time consistent backups, including databases. For example, with MySQL, you can freeze and flush all the databases, snapshot the LV, and release the freeze. MySQL takes a brief pause (few seconds), and then you mount and back up the snapshot for a fully consistent database (only way to do that other than freezing all writes during a mysqldump, which can take a long time for larger DBs). That also avoids the access-time churn (for backup programs that don't know O_NOATIME, like any that use rsync). That's server stuff. On a desktop with a combination of SSD and spinning rust drives, LVM can give you transparent SSD caching of hot data (rather than you having to put some filesystems on SSD and some on hard drive). Now, if btrfs ever gets all the kinks worked out (and has a stable fsck for the corner cases), it integrates volume management into the filesystem, which makes some of the management easier. I used AdvFS on DEC/Compaq/HP Tru64 Unix, which had some of that, and it made some of this easier/faster/smoother. Btrfs may eventually obsolete a lot of uses of LVM, but that's down the road. -- Chris Adams li...@cmadams.net ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On 6/24/2015 1:06 PM, m.r...@5-cent.us wrote: Gordon Messmer wrote: On 06/23/2015 08:10 PM, Marko Vojinovic wrote: Ok, you made me curious. Just how dramatic can it be? From where I'm sitting, a read/write to a disk takes the amount of time it takes, the hardware has a certain physical speed, regardless of the presence of LVM. What am I missing? Well, there's best and worst case scenarios. Best case for file-backed VMs is pre-allocated files. It takes up more space, and takes a while to set up initially, but it skips block allocation and probably some fragmentation performance hits later. Worst case, though, is sparse files. In such a setup, when you write a new file in a guest, the kernel writes the metadata to the journal, then MVNCH Here's a question: all of the arguments you're giving have to do with VMs. Do you have some for straight-on-the-server, non-VM cases? mark Is there an easy to follow howto for normal LVM administration tasks. I get tired of googling every-time I have to do something I don't remember how to do regarding LVM, so I usually just don't bother with it at all. I believe it has some benefit for my use cases, but I've been reticent to use it, since the last time I got LVM problems, I lost everything on the volume, and had to restore from backups anyway. I suspect I shot myself in the foot, but I still don't know for sure. thanks, -chuck -- ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] LVM hatred, was Re: /boot on a separate partition?
On 6/23/2015 10:33 AM, Marko Vojinovic wrote: Inside / (which is mostly always ext4), 100% of the time. :-) That said, I prefer virtual machines over multiboot environments, and I absolutely despise LVM --- that cursed thing is never getting on my drives. Never again, that is... I'm curious what has made some people hate LVM so much. I have been using it for years on thousands of production systems with no issues that could not be easily explained as myself or someone else doing something stupid. And even those issues were pretty few and far between. /opens can of worms HTH, :-) Marko ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On Tue, 23 Jun 2015 11:15:30 -0500 Jason Warr ja...@warr.net wrote: I'm curious what has made some people hate LVM so much. I have been using it for years on thousands of production systems with no issues that could not be easily explained as myself or someone else doing something stupid. And even those issues were pretty few and far between. /opens can of worms Well, I can only tell you my own story, I wouldn't know about other people. Basically, it boils down to the following: (1) I have no valid usecase for it. I don't remember when was the last time I needed to resize partitions (probably back when I was trying to install Windows 95). Disk space is very cheap, and if I really need to have *that* much data on a single partition, another drive and a few intelligently placed symlinks are usually enough. Cases where a symlink cannot do the job are indicative of a bad data structure design, and LVM is often not a solution, but a patch over a deeper problem elsewhere. Though I do admit there are some valid usecases for LVM. (2) It is fragile. If you have data on top of LVM spread over an array of disks, and one disk dies, the data on the whole array goes away. I don't know why such a design of LVM was preferred over something more robust (I guess there are reasons), but it doesn't feel right. A bunch of flawless drives containing corrupt data is Just Wrong(tm). I know, one should always have backups, but still... (3) It's being pushed as default on everyday ordinary users, who have absolutely no need for it. I would understand it as an opt-in feature that some people might need in datacenters, drive farms, clouds, etc., but an ordinary user installing a single OS on their everyday laptop just doesn't need it. Jumping through hoops during installation to opt-in LVM by a small number of experts outweighs similar jumping to opt-out of it by a large number of noobs. Also, related to (3), there was that famous Fedora upgrade fiasco a few Fedora releases back. It went like this: * A default installation included LVM for all partitions, except for /boot, since grub couldn't read inside LVM. * Six months later, the upgrade process to the next release of Fedora happened to require a lot of space in /boot, more than the default settings. * The /boot partition, being the only one outside LVM, was the only one that couldn't be resized on-the-fly. * People who opted-out of LVM usually didn't have a reason to create a separate /boot partition, but bundled it under /, circumventing the size issue in advance without even knowing it. So the story ended up with lots of people in upgrading griefs purely because they couldn't resize the separate /boot partition, and it was separate because LVM was present, and LVM was present with the goal of making partition resizing easy! A textbook example of a catch-22, unbelievable!! Of course, I know what you'll say --- it wasn't just LVM, but an unfortunate combination of LVM, limitations of grub, bad defaults and a lousy upgrade mechanism. And yes, you'd be right, I agree. But the bottomline was that people with LVM couldn't upgrade (without bending backwards), while people without LVM didn't even notice that there is a problem. And since hatred is an irrational thing, you need not look any further than that. ;-) Best, :-) Marko ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On Tue, Jun 23, 2015 at 12:15 PM, Jason Warr ja...@warr.net wrote: On 6/23/2015 10:33 AM, Marko Vojinovic wrote: Inside / (which is mostly always ext4), 100% of the time. :-) That said, I prefer virtual machines over multiboot environments, and I absolutely despise LVM --- that cursed thing is never getting on my drives. Never again, that is... I'm curious what has made some people hate LVM so much. I have been using it for years on thousands of No clue. My experiences with LVM have been positive as well. And in opinion it doesn't add much complexity (if you know the LVM tools, you're fine). Flexibility is worth an ounce of complexity. production systems with no issues that could not be easily explained as myself or someone else doing something stupid. And even those issues were pretty few and far between. The worst nail biter I had was an instance where a former employee did not properly allocate LV space to /var and I had to reclaim space from rootfs and add it to /var. Even a small screw up and I'd have to go recover from my backups (not fun). Fortunately I spun up VMs and labbed everything a few times over and wrote detailed notes. Went without a hitch. Prior Proper Planning Prevents Poor Performance /opens can of worms I'll bite, see above ;-) HTH, :-) Marko ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos -- ---~~.~~--- Mike // SilverTip257 // ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On Tue, Jun 23, 2015 at 1:54 PM, Marko Vojinovic vvma...@gmail.com wrote: On Tue, 23 Jun 2015 11:15:30 -0500 Jason Warr ja...@warr.net wrote: I'm curious what has made some people hate LVM so much. I have been using it for years on thousands of production systems with no issues that could not be easily explained as myself or someone else doing something stupid. And even those issues were pretty few and far between. /opens can of worms Well, I can only tell you my own story, I wouldn't know about other people. Basically, it boils down to the following: (1) I have no valid usecase for it. I don't remember when was the last time I needed to resize partitions (probably back when I was trying to install Windows 95). Disk space is very cheap, and if I really need to have *that* much data on a single partition, another drive and a few intelligently placed symlinks are usually enough. Cases where a symlink cannot do the job are indicative of a bad data structure design, and LVM is often not a solution, but a patch over a deeper problem elsewhere. Though I do admit there are some valid usecases for LVM. AIX does use lvm a lot. Main difference is their filesystem allows live shrinking. Kinda nice to dynamically size a partition depending on needs, as opposite to the so often suggested approach of formatting the entire drive as one single partition. Symlinking is great until whatever the destination is does not mount. I myself use lvm as disks for my vm clients, which xenserver does too (not my fault I promise!). It is faster than an image file. (2) It is fragile. If you have data on top of LVM spread over an array of disks, and one disk dies, the data on the whole array goes away. I don't know why such a design of LVM was preferred over something more robust (I guess there are reasons), but it doesn't feel right. A bunch of flawless drives containing corrupt data is Just Wrong(tm). I know, one should always have backups, but still... Building a raid0, which is what your example is, and hoping data will survive in case of a drive failure is wishful thinking. You can build VLM on the top of a proper raid, or do raid inside lvm nowadayas... just like zfs, (3) It's being pushed as default on everyday ordinary users, who have absolutely no need for it. I would understand it as an opt-in feature that some people might need in datacenters, drive farms, clouds, etc., but an ordinary user installing a single OS on their everyday laptop just doesn't need it. Jumping through hoops during installation to opt-in LVM by a small number of experts outweighs similar jumping to opt-out of it by a large number of noobs. That is not lvm's fault, but the distro's decision. Also, related to (3), there was that famous Fedora upgrade fiasco a few Fedora releases back. It went like this: * A default installation included LVM for all partitions, except for /boot, since grub couldn't read inside LVM. * Six months later, the upgrade process to the next release of Fedora happened to require a lot of space in /boot, more than the default settings. * The /boot partition, being the only one outside LVM, was the only one that couldn't be resized on-the-fly. * People who opted-out of LVM usually didn't have a reason to create a separate /boot partition, but bundled it under /, circumventing the size issue in advance without even knowing it. Fedora != lvm unless I have been lied to all these years. So the story ended up with lots of people in upgrading griefs purely because they couldn't resize the separate /boot partition, and it was separate because LVM was present, and LVM was present with the goal of making partition resizing easy! A textbook example of a catch-22, unbelievable!! Of course, I know what you'll say --- it wasn't just LVM, but an unfortunate combination of LVM, limitations of grub, bad defaults and a lousy upgrade mechanism. And yes, you'd be right, I agree. But the bottomline was that people with LVM couldn't upgrade (without bending backwards), while people without LVM didn't even notice that there is a problem. And since hatred is an irrational thing, you need not look any further than that. ;-) Best, :-) Marko ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
Marko Vojinovic wrote: On Tue, 23 Jun 2015 11:15:30 -0500 Jason Warr ja...@warr.net wrote: I'm curious what has made some people hate LVM so much. I have been using it for years on thousands of production systems with no issues that could not be easily explained as myself or someone else doing something stupid. And even those issues were pretty few and far between. /opens can of worms Well, I can only tell you my own story, I wouldn't know about other people. Basically, it boils down to the following: (1) I have no valid usecase for it. I don't remember when was the last time I needed to resize partitions (probably back when I was trying to install Windows 95). Disk space is very cheap, and if I really need to have *that* much data on a single partition, another drive and a few intelligently placed symlinks are usually enough. Cases where a symlink cannot do the job are indicative of a bad data structure design, and LVM is often not a solution, but a patch over a deeper problem elsewhere. Though I do admit there are some valid usecases for LVM. (2) It is fragile. If you have data on top of LVM spread over an array of disks, and one disk dies, the data on the whole array goes away. I don't know why such a design of LVM was preferred over something more robust (I guess there are reasons), but it doesn't feel right. A bunch of flawless drives containing corrupt data is Just Wrong(tm). I know, one should always have backups, but still... snip I thought it was interesting years ago, having seen and worked with it in Tru64. These days, if I needed more space, I'd go with plain RAID. In general, the less complex the better, and the easier to recover when something fails. mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On 6/23/2015 11:23 AM, Mauricio Tavares wrote: AIX does use lvm a lot. Main difference is their filesystem allows live shrinking. Kinda nice to dynamically size a partition depending on needs, as opposite to the so often suggested approach of formatting the entire drive as one single partition. Symlinking is great until whatever the destination is does not mount. I myself use lvm as disks for my vm clients, which xenserver does too (not my fault I promise!). It is faster than an image file. While it has the same concepts, physical volumes, volume groups, logical volumes, the LVM in AIX shares only the initials with Linux. I've heard that Linux's LVM was based on HP-UX's design. in AIX, the LVM is tightly integrated with file system management, so you issue the command to grow a file system, and it automatically grows the underlying logical volume. the OS itself can automatically grow file systems when its installing software. Also, in AIX, the volume manager is the raid manager, you say 'copies = 2' as an attribute of a LV, and data is mirrored. -- john r pierce, recycling bits in santa cruz ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On Tue, 23 Jun 2015 14:23:52 -0400 Mauricio Tavares raubvo...@gmail.com wrote: On Tue, Jun 23, 2015 at 1:54 PM, Marko Vojinovic vvma...@gmail.com wrote: On Tue, 23 Jun 2015 11:15:30 -0500 Jason Warr ja...@warr.net wrote: I'm curious what has made some people hate LVM so much. (3) It's being pushed as default on everyday ordinary users, who have absolutely no need for it. That is not lvm's fault, but the distro's decision. Agreed, but remember that hatred is not a rational thing. When one sees LVM being pushed onto them by their favorite distro, they are not going to blame the distro (because it's their favorite distro, you know...), but rather the LVM itself. Psychology is a curious thing. ;-) Also, related to (3), there was that famous Fedora upgrade fiasco a few Fedora releases back. It went like this: Fedora != lvm unless I have been lied to all these years. That Fedora stunt was just one real-world example of how things can get drastically wrong, and for a sizable number of people. I wasn't criticizing LVM, I was answering why some people hate it. :-) As far as an ordinary noob user thinks, this is how it goes. Things that participated in the problem were: - upgrade software, - boot partition, - grub bootloader, - LVM. A typical noob user knows they need the first three components for day-to-day work, and that they don't need the fourth. Also, people who didn't have the fourth component didn't have the problem. Guess which of the four will catch the blame? Moreover, the fourth component failed to help with the problem, despite it being there precisely for partition resizing. There's nothing more to discuss, it's clear as day... :-D Remember, I'm not justifying this reasoning, just reporting what I've seen happen out in the wild, and why some people hate LVM. ;-) Best, :-) Marko ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
Marko Vojinovic wrote: On Tue, 23 Jun 2015 14:23:52 -0400 Mauricio Tavares raubvo...@gmail.com wrote: On Tue, Jun 23, 2015 at 1:54 PM, Marko Vojinovic vvma...@gmail.com wrote: On Tue, 23 Jun 2015 11:15:30 -0500 Jason Warr ja...@warr.net wrote: I'm curious what has made some people hate LVM so much. (3) It's being pushed as default on everyday ordinary users, who have absolutely no need for it. That is not lvm's fault, but the distro's decision. Agreed, but remember that hatred is not a rational thing. When one sees snip Hold on thar, pardner. I don't hate LVM, but don't care for it. And in most cases, or at least my own, and the person who is vehemently against it, it's based on personal experience. How is that not a rational thing? For that matter, haven't you ever gotten gunshy when something that's billed as the LATESTGREATESTTHINGSINCESLICEDBREAD is buggy, and not ready for prime time? Certainly 10-12 years ago, that's how I felt about python, where literally every sub-release broke what was running. Is it irrational to be unappreciative of it? (We'll ignore my unhappiness at the whole concept of whitespace as a syntax element.) Or then there's systemd mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On 6/23/2015 3:31 PM, m.r...@5-cent.us wrote: Marko Vojinovic wrote: On Tue, 23 Jun 2015 14:23:52 -0400 Mauricio Tavares raubvo...@gmail.com wrote: On Tue, Jun 23, 2015 at 1:54 PM, Marko Vojinovic vvma...@gmail.com wrote: On Tue, 23 Jun 2015 11:15:30 -0500 Jason Warr ja...@warr.net wrote: I'm curious what has made some people hate LVM so much. (3) It's being pushed as default on everyday ordinary users, who have absolutely no need for it. That is not lvm's fault, but the distro's decision. Agreed, but remember that hatred is not a rational thing. When one sees snip Hold on thar, pardner. I don't hate LVM, but don't care for it. And in most cases, or at least my own, and the person who is vehemently against it, it's based on personal experience. How is that not a rational thing? The only thing that could be irrational about it is if you were to say It does not work for me now so how can it work for anyone, ever? I have not seen any of you guys taking that attitude but some do. Recommending against using LVM and citing reasons based on your experience with it is certainly valid and basically why I asked the question in the first place. I have not come across any serious blockers and was curious what made it blockers for some of you. For that matter, haven't you ever gotten gunshy when something that's billed as the LATESTGREATESTTHINGSINCESLICEDBREAD is buggy, and not ready for prime time? Certainly 10-12 years ago, that's how I felt about python, where literally every sub-release broke what was running. Is it irrational to be unappreciative of it? (We'll ignore my unhappiness at the whole concept of whitespace as a syntax element.) Or then there's systemd mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On Tue, 23 Jun 2015 18:42:13 -0700 Gordon Messmer gordon.mess...@gmail.com wrote: I wondered the same thing, especially in the context of someone who prefers virtual machines. LV-backed VMs have *dramatically* better disk performance than file-backed VMs. Ok, you made me curious. Just how dramatic can it be? From where I'm sitting, a read/write to a disk takes the amount of time it takes, the hardware has a certain physical speed, regardless of the presence of LVM. What am I missing? For concreteness, let's say I have a guest machine, with a dedicated physical partition for it, on a single drive. Or, I have the same thing, only the dedicated partition is inside LVM. Why is there a performance difference, and how dramatic is it? If you convince me, I might just change my opinion about LVM. :-) Oh, and just please don't tell me that the load can be spread accross two or more harddrives, cutting the file access by a factor of two (or more). I can do that with raid, no need for LVM. Stick to a single harddrive scenario, please. Best, :-) Marko ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On Tue, 23 Jun 2015 19:08:24 -0700 Gordon Messmer gordon.mess...@gmail.com wrote: Such as: 1) LVM makes MBR and GPT systems more consistent with each other, reducing the probability of a bug that affects only one. 2) LVM also makes RAID and non-RAID systems more consistent with each other, reducing the probability of a bug that affects only one. OTOH, it increases the probability of a bug that affects LVM itself. But really, these arguments sound like a strawman. It reduces the probability of a bug that affects one of the setups --- I have a hard time imagining a real-world usecase where something like that can be even observable, let alone relevant. 3) MBR has silly limits on the number of partitions, that don't affect LVM. Sure, GPT is better, but so long as both are supported, the best solution is the one that works in both cases. That only makes sense if I need a lot of partitions on a system that doesn't support GPT. Sure, that can happen (ever more rarely on modern hardware), but I wouldn't know how common it is. I rarely needed many partitions in my setups. 4) There are lots of situations where you might want to expand a disk/filesystem on a server or virtual machine. Desktops might do so less often, but there's no specific reason to put more engineering effort into making the two different. The best solution is the one that works in both cases. What do you mean by engineering effort? When I'm setting up a data storage farm, I'll use LVM. When I'm setting up my laptop, I won't. What effort is there? I just see it as an annoyance of having to customize my partition layout on the laptop, during the OS installation (customizing a storage farm setup is pretty mandatory either way, so it doesn't make a big difference). 5) Snapshots are the only practical way to get consistent backups, and you should be using them. That depends on what kind of data you're backing up. If you're backing up the whole filesystem, than I agree. But if you are backing up only certain critical data, I'd say that a targeted rsync can be waaay more efficient. 6) If you use virtualization, LV-backed VMs are dramatically faster than file-backed VMs. I asked for an explanation of this in the other e-mail. Let's keep it there. LVM has virtually zero cost, so there's no practical benefit to not using it. If you need it. If you don't need it, there is no practical benefit of having it, either. It's just another potential point of failure, waiting to happen. The point of view that LVM isn't needed when a symlink will do is no more valid than the opposite point of view: that there's no reason to play stupid games with symlinks when you have the ability to manage volumes. I would agree with this, up to the point of fragility/robustness (see below). (2) It is fragile. If you have data on top of LVM spread over an array of disks, and one disk dies, the data on the whole array goes away. That's true of every filesystem that doesn't use RAID or something like it. It's hardly a valid criticism of LVM. If you have a sequence of plain ext4 harddrives with several symlinks, and one drive dies, you can still read the data sitting on the other drives. With LVM, you cannot. It's as simple as that. In some cases it makes sense to maintain access to reduced amount of data, despite the fact that a chunk went missing. A webserver, for example, can keep serving the data that's still there on the healthy drives, and survive the failure of the faulty drive without downtime. OTOH, with LVM, once a single drive fails, the server looses access to all data, which then necessitates some downtime while switching to the backup, etc. LVM isn't always an optimal solution. And since hatred is an irrational thing, you need not look any further than that. ;-) Well, let's not forget that you are the one who said that you despise LVM. As long as you recognize that you aren't rational, I suppose we agree on at least one thing. :) Oh, of course! :-) The ability to be irrational is what makes us human. Otherwise life would be very boring. ;-) Best, :-) Marko ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On 06/23/2015 09:15 AM, Jason Warr wrote: That said, I prefer virtual machines over multiboot environments, and I absolutely despise LVM --- that cursed thing is never getting on my drives. Never again, that is... I'm curious what has made some people hate LVM so much. I wondered the same thing, especially in the context of someone who prefers virtual machines. LV-backed VMs have *dramatically* better disk performance than file-backed VMs. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LVM hatred, was Re: /boot on a separate partition?
On 06/23/2015 10:54 AM, Marko Vojinovic wrote: (1) I have no valid usecase for it. I don't remember when was the last time I needed to resize partitions (probably back when I was trying to install Windows 95). Disk space is very cheap, and if I really need to have *that* much data on a single partition, another drive and a few intelligently placed symlinks are usually enough. Cases where a symlink cannot do the job are indicative of a bad data structure design, and LVM is often not a solution, but a patch over a deeper problem elsewhere. Though I do admit there are some valid usecases for LVM. Such as: 1) LVM makes MBR and GPT systems more consistent with each other, reducing the probability of a bug that affects only one. 2) LVM also makes RAID and non-RAID systems more consistent with each other, reducing the probability of a bug that affects only one. 3) MBR has silly limits on the number of partitions, that don't affect LVM. Sure, GPT is better, but so long as both are supported, the best solution is the one that works in both cases. 4) There are lots of situations where you might want to expand a disk/filesystem on a server or virtual machine. Desktops might do so less often, but there's no specific reason to put more engineering effort into making the two different. The best solution is the one that works in both cases. 5) Snapshots are the only practical way to get consistent backups, and you should be using them. 6) If you use virtualization, LV-backed VMs are dramatically faster than file-backed VMs. LVM has virtually zero cost, so there's no practical benefit to not using it. When btrfs comes along and supports flexible volumes, snapshots, and reliable storage, then it'll make sense to ditch LVM. Until then, LVM shouldn't even be a question; the answer is yes. The point of view that LVM isn't needed when a symlink will do is no more valid than the opposite point of view: that there's no reason to play stupid games with symlinks when you have the ability to manage volumes. (2) It is fragile. If you have data on top of LVM spread over an array of disks, and one disk dies, the data on the whole array goes away. That's true of every filesystem that doesn't use RAID or something like it. It's hardly a valid criticism of LVM. And since hatred is an irrational thing, you need not look any further than that. ;-) Well, let's not forget that you are the one who said that you despise LVM. As long as you recognize that you aren't rational, I suppose we agree on at least one thing. :) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
