From ArchWiki
Jump to navigation Jump to search

LVM-recovery section

Would a section on LVM un-borkage be useful and/or within the scope of this article? Buhman 13:45, 29 April 2012 (UTC)

All constructive contributions are welcome. However if you're going to simply rewrite some existing and well maintained documentation, it'd be better to just write an introduction and link to it; if instead you want to write an Arch-oriented section or something more original in general, then go for it :) -- Kynikos 09:53, 30 April 2012 (UTC)

PROS and CONS (citing needed)

Can anybody please come up with and elaborate on some of the cons as to what the drawbacks in performance and wear and tear would be when having multple LVM partitions spread and intertwined across several hard drives? (vs. keeping partitions spread evenly and limited to one drive only)

Cons should be clearly listed on the main 'page' ("cons", or "disadvantages", maybe near "advantages")

In fact, upon reading the 'advantages' section is what had me anticipating there would be something on disadvantages. I'm concerned about hard performance testing results. Has anyone seen any good data on this?

I did some work on this, consolidating the advantages which where listed in 2 different sections before. I picked some disadvantages which come to my mind, also some points from the german language version of the article.
No idea if there is any performance impact of lvm.
Also i removed 2 points in advantages:
  • Name your VG and LV as you like -> Don't see that as adv. when compared to normal partitions. That you can name them is nice, it would be pretty mean if you could not.
  • No need for an extended partition -> Never saw the extended/logical-partition thing as anything more than a minor wart from a user perspective.

Bwid (talk) 12:25, 11 March 2013 (UTC)

I am closing this because i think the main focus of the article should be what LVM is, basic setup and some a little more advanced topics like Snapshots. However, going into performance comparission of Single-HD vs. Multiple-HD is: 1. Labor intensive, and i think nobody has time to do the work 2. Results would be Application specific. 3. The Scope of the article would get very large if the question where covered in detail. Bwid (talk) 14:16, 14 September 2014 (UTC)

Does swap really need to be on a contiguous volume?

Lvm#Create logical volumes and Dm-crypt/Encrypting an entire system suggest to create contiguous logical volumes for swap with lvcreate -C y, but is this really needed? And why? [1], [2], [3], [4] and [5] seem to bust the myth. -- Kynikos (talk) 02:58, 6 September 2014 (UTC)

Also [6]. Bwid (talk) 05:33, 6 September 2014 (UTC)
Interesting question. Imo it certainly is not needed, but was likely used here (back in 2008, wow:) because fragmentation (and resulting HDD seek times) otherwise may slow down the lv, and fragmented lv-swap (as ram replacement) slows down the system even more. That said I don't have a reference for this assumption, just seems logical to me. (In a multiple pv setup -C y may be even disadvantageous but that certainly goes too far for the article). For a similar reason (disk speed) swap was often created as the first lv on a fresh drive, because throughput on the outer HDD edge, which likely gets allocated first, is faster.
I'd be +1 to mark the parameter as optional, or even remove it due to lack of reference for it. Other opinions (or a recent reference even)? --Indigo (talk) 09:26, 6 September 2014 (UTC)
For the moment I've removed the flag where it was used. Maybe we can restore it in a Tip in LVM#Create logical volumes if we provide some justification, but certainly it doesn't belong in Dm-crypt/Encrypting an entire system. -- Kynikos (talk) 14:45, 7 September 2014 (UTC)
Ok, but I'm curious why you write it "certainly" does not belong into the dm-crypt scenario? I'd argue (a) with LVM on LUKS you cannot run into problems with multiple pv's per se and (b) while the option was proposed as default in this article it might as well be used with dm-crypt as well (if there is any speed advantage to it, it does apply there too and crypto is unaffected).
In any case, I looked into it again re creating a tip for this article and now think we should just leave it out (no tip). Reason: -C y is linked to and overrides the default lvm allocation policy (--alloc normal). The default policy will try contiguous allocation for a fresh setup/disk anyhow, but not fail. In case of a lack of contiguous extents it will try the next policy and following volumes "inherit" the policy from the vg. A problem, however, may arise if you later want to extent a volume which has "contiguous" set explicitly. Then you either have to move volumes [7] to create free contiguous extents or change the policy again [8]. Hence, -C y explicitly is indeed bound to create problems and if add a tip for it, it must cover a lot incl. --alloc and potential pitfalls. --> Let's leave it out of scope for this article and stick to defaults. It's a little deprecated anyway in times of SSDs and fast HDDs with cache. --Indigo (talk) 16:29, 12 September 2014 (UTC)
Thank you for your considerations, let's discard the Tip idea.
I wrote that -Cy doesn't "certainly" belong in that dm-crypt scenario because that example should be as simple as possible (it's not about LVM, it's about dm-crypt): if somebody wants a contiguous volume for some reason, he'll read LVM's documentation.
I think I can close this discussion. -- Kynikos (talk) 03:56, 13 September 2014 (UTC)
Thanks for the answer and sorry I reply after closing. Just wanted to note that I later figured we have a troubleshoot section here, which is a good place for the last links we collected above (also having in mind we had the option "-C y" for long). So I just went ahead and added the last links above to it with collected info to a troubleshoot item (instead of a tip): [9] to get it off the mind.
--Indigo (talk) 12:02, 14 September 2014 (UTC)