These tags don't seem that different. lvm has a tag wiki, whereas lvm2 does not, leading me to use lvm for my recent LVM2 question. Is there any difference between these, or should one go away? Possibly we could have an lvm1 tag for anyone who's still using the old version?
2 Answers
I don't recall seeing a question about LVM1 on this site. It was already obsolete by the time this site started. So for all intents and purposes lvm and lvm2 are currently equivalent.
I favor merging them, and making lvm the main tag. (Only moderators can do this.)
If an incompatible LVM3 comes along, we can start using lvm3 for it. Then make lvm2 the main tag in the lvm/lvm2 pair and remove the synonym.
Which reminds me, grub is a mess. We have plenty of questions about Grub 1, but Grub 2 questions have also been tagged grub, especially as Grub 1 is now obsolete.
-
1Even though grub 1 is obsolete, it will be in production use for a while longer since RHEL5 uses it.– jordanmSep 23, 2013 at 22:50
-
4Just rename everything to grub, the distinction isn't that useful and couldn't be made unambiguously with the existing two tags.– GabrielSep 24, 2013 at 16:08
-
On the issue of grub, couldn't
grub
just be re-purposed forgrub2
and agrub1
tag created for the RHEL-based distros? If the feeling is that grub1 shouldn't be expected to be what people are going for as things progress. I think the distinction is very useful since there are important differences between the two. Sep 24, 2013 at 17:01 -
1@Joel I don't find the split useful for subscription/highlighting purposes, and I wouldn't trust the version if the asker doesn't put it in plain text.– GabrielSep 24, 2013 at 18:14
-
Just my two cents:
It might create noise, but having lvm
in the general neighborhood of lvm2
doesn't really mess things up. There's ambiguity but I don't think it's going to make or break any assumptions people could reasonably be expected to make about the question.
If there does need to be a change, from what I can see there are two possibly legitimate uses of the tag:
1) As a reference to LVM1 as Gilles mentioned. It might be worthwhile to maintain the distinction as someone may have a question about the origins of the current LVM design and referencing a previous iteration might be a good reference point. If LVM2 ever gets marginalized in the enterprise by newer technologies, that would marginalize LVM1 to the point where it's so corner case as to be make this desire moot.
-----------
2) This is pretty close to how it is now, and I'd prefer it this way: It also may be worthwhile to reference "Logical Volume Management" as a whole, which (reading the description) seems like it basically was intended to be and it just wasn't made explicit. This is useful since "LVM" is a pretty broad topic, and providing a catch-all tag for anything under that particular tent may help people attract interested eyeballs to their question. For example, clvm
could have its own tag as does lvm2
. If I'm having an issue with clustered LVM, though, lvm2
feels like the wrong tag to put onto it since my problem isn't related to the particular version of LVM I'm running (except insofar as LVM2 is the only one that supports clustering, which isn't definitional identity since any forthcoming LVM3 would likely have that functionality as well). There's a similar case with HA-LVM.
Also, having a catch-all tag also helps for questions that are likely going to be relevant to all LVM incarnations (such as metadata recovery). Having general questions that are likely to be applicable to people new to the over-all paradigm share a common tag is also useful. For example, if someone is just unfamiliar with the concepts of volume group/physical volume, snapshots, etc.
Almost all my LVM2-related posts are tagged as lvm
for this reason, I only use lvm2
if I'm in the mood to be super specific. People are going to assume lvm2 and even if the two were on parity, the onus should be on the asker to clear up ambiguity whether it's this or some other part of their question.
Whichever is decided (assuming I'm not overlooking a third option) updating the description to make it explicit is probably still desirable.