Seen them while running a few servers and a few TB of data. To me the LVM2 in Linux feels like a "clever idea" someone had. Like some of these, they turn out to be "not clever" at times.
Well, just that this separation was there for a reason - the differences show with PV loss handling, and online re-activation of a VG with i. And don't even get me talking about Quorum loss detection haha or state handling if I remove a disk, that won't be flagged as unavailable. It doesn't even have the damn status column. Just now I look at a disk where the phyiscal lvm data still is hung on the state from mid-pvmove. There have been some memleaks I think, and the general idea it's a good thing to copy around live block data from userspace is just sad.
Nice quote from the lvm list "seems like vgreduce --missing does not handle pvmove" Means in fact if a disk detaches during pvmove then the lvm management tool changes from lvm to vi. Re: Snapshots The CoW is done unsafely, by updating the NEW data into the snapshot lv area and then merging back once you delete the snap.
This means you have heavy IO spikes during the final merge-back of new data into the original LV and, much more important, you of course also have a much higher risk of data corruption, because not the snapshot will be broken once you hit the wall, but the original. The advantage is in performance, doing 1 writes instead of 3.
Picking the fast but unsafer algorithm is something that one obviously expects from people like VMware and MS, on "Unix" I'd rather guess things would be "done right". I didn't see much performance issues as long as I have the snapshot backing store on a different disk drive than the primary data and backup to yet another one of course.
It was a devmapper issue, as far as I know. But there can be some blame for not really caring about this issue from at least kernel 2. Or it uses GiB.
That should give the correct net size, and that issue is always a usage issue. Of course it's telling that you can't find good sources for such info. Update a few months later: I have been hitting the "full snapshot" scenario for a test by now. If they get full, the snapshot blocks, not the original LV. I was wrong there when I had first posted this.
I picked up wrong info from some doc, or maybe I had understood it. In my setups I'd always been very paranoid to not let them fill up and so I never ended up corrected. What I've still been unable to solve is how to identify a snapshot's age. As to their performance, there is a note on the "thinp" fedora project page which says the snapshot technique is being revised so that they won't get slower with each snapshot.
I don't know how they're implementing it. If you plan to use snapshots for backups - be prepared for a major performance hit when snapshot is present. I've been using lvm in production for couple of years on dozens of servers, although my main reason to use it is the atomic snapshot not ability to expand volumes easily. BTW if you're going to use 1TB drive, remember about partition alignment - this drive most probably has 4kB physical sectors. Modern ie: post LVM :. Obviously, this does not mean you always have to use LVM - the golden rule for storage is to avoid unneeded layers.
For example, for simple virtual machines you can surely go ahead with classical partition only. But if you value any of the features above, LVM is an extremely useful tool which should be in the toolbox of any serious Linux sysadmin.
Another advantage: you can add a new physical volume PV , move all the data to that PV and then remove the old PV without any service interruptions. I've used that capability at least four times in the past five years. A disadvantage I didn't see pointed out clearly yet: There's a somewhat steep learning curve for LVM2. Mostly in the abstraction it creates between your files and the underlying media.
If you work with just a few people who share chores on a set of servers, you may find the extra complexity overwhelming for your team as a whole. Larger teams dedicated to the IT work will generally not have such a problem.
For example, we use it widely here at my work and have taken time to teach the whole team the basics, the language and the bare essentials about recovering systems that don't boot correctly. One caution specifically to point out: if you boot from an LVM2 logical volume you made find recovery operations difficult when the server crashes. Knoppix and friends don't always have the right stuff for that.
This is what your filesystems will look like if you scale your VM's storage laterally:. I've seen lots of confusion over this. Here's the answer illustrated:. Logically, this is what we should expect. If the extents holding our LV data are spread across multiple PVs and one of those PVs disappears, the filesystem in that LV would be catastrophically damaged.
Hope these little doodles made a complex subject a bit easier to understand the risks when working with LVM. Sign up to join this community. The best answers are voted up and rise to the top. Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams?
Learn more. LVM dangers and caveats Ask Question. Asked 10 years, 7 months ago. Active 1 month ago. Viewed 79k times. What are the downsides of using LVM? Improve this question. RichVel 3, 1 1 gold badge 16 16 silver badges 23 23 bronze badges. Adam Matan Adam Matan When reading the answers to this question, bear in mind the date year they were posted. A lot happens in 3 years in this industry.
I've done some updates recently Apr having scanned through to see if anything has changed. The 2. The state of write caching, filesystem resizing and LVM snapshots haven't really changed much as far as I can see.
Add a comment. Active Oldest Votes. Summary Risks of using LVM: Vulnerable to write caching issues with SSD or VM hypervisor Harder to recover data due to more complex on-disk structures Harder to resize filesystems correctly Snapshots are hard to use, slow and buggy Requires some skill to configure correctly given these issues The first two LVM issues combine: if write caching isn't working correctly and you have a power loss e.
The main LVM risks and issues I'm aware of are: Vulnerable to hard disk write caching due to VM hypervisors, disk caching or old Linux kernels , and makes it harder to recover data due to more complex on-disk structures - see below for details. Write caching and write re-ordering by the hard drive is important to good performance, but can fail to flush blocks to disk correctly due to VM hypervisors, hard drive write caching, old Linux kernels, etc.
Write barriers mean the kernel guarantees that it will complete certain disk writes before the "barrier" disk write, to ensure that filesystems and RAID can recover in the event of a sudden power loss or crash. Such barriers can use a FUA Force Unit Access operation to immediately write certain blocks to the disk, which is more efficient than a full cache flush. Check your hypervisor documentation carefully for a "flush to disk" or write-through cache option present in KVM , VMware , Xen , VirtualBox and others - and test it with your setup.
Some hypervisors such as VirtualBox have a default setting that ignores any disk flushes from the guest. Enterprise servers with LVM should always use a battery backed RAID controller and disable the hard disk write caching the controller has battery backed write cache which is fast and safe - see this comment by the author of this XFS FAQ entry.
It may also be safe to turn off write barriers in the kernel, but testing is recommended. If you don't have a battery-backed RAID controller, disabling hard drive write caching will slow writes significantly but make LVM safe. Or use ext4 which enables barriers by default. This is the simplest option and provides good data integrity at cost of performance. If you are using Advanced Format drives i.
Very old Linux kernels 2. If these old 2. Losing 32MB of the most recently written FS metadata and journal data, which the kernel thinks is already on disk, usually means a lot of FS corruption and hence data loss.
Unfortunately, some hard drives and SSDs lie about whether they have really flushed their cache to the disk particularly older drives, but including some SATA drives and some enterprise SSDs - more details here. There is a great summary from an XFS developer. There's a simple test tool for lying drives Perl script , or see this background with another tool testing for write re-ordering as a result of the drive cache.
This answer covered similar testing of SATA drives that uncovered a write barrier issue in software RAID - these tests actually exercise the whole storage stack. If your hard drives or SSDs do lie about flushing their cache to disk, you really can't rely on write barriers and must disable write caching. Some cheaper SSDs have issues that can't be fixed with write-cache configuration - the PostgreSQL project's mailing list and Reliable Writes wiki page are good sources of information.
Consumer SSDs can have major write caching problems that will cause data loss, and don't include supercapacitors so are vulnerable to power failures causing corruption. Advanced Format drive setup - write caching, alignment, RAID, GPT With newer Advanced Format drives that use 4 KiB physical sectors, it may be important to keep drive write caching enabled, since most such drives currently emulate byte logical sectors " emulation" , and some even claim to have byte physical sectors while really using 4 KiB.
Testing is recommended to confirm any impact if you disable the cache. This LVM email list thread points to the work done in kernels during and the issue of partial block writes when mixing disks with byte and 4 KiB sectors in a single LV.
Harder to recover data due to more complex on-disk structures : Any recovery of LVM data required after a hard crash or power loss due to incorrect write caching is a manual process at best, because there are apparently no suitable tools. Hence a full restore from backup is likely to be required. This involves a lot more downtime than a quick journal-based fsck when not using LVM, and data written since the last backup will be lost.
Search titles only. Search Advanced search…. Everywhere Threads This forum This thread. Search Advanced…. New posts. Search forums. Install the app. Thread starter nanonettr Start date Sep 1, JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding. You are using an out of date browser. It may not display this or other websites correctly. You should upgrade or use an alternative browser.
Jul 25, 17 0
0コメント