Red Hat Bugzilla – Bug 166762
Installer chooses misleading names for logical volumes
Last modified: 2008-06-26 06:51:16 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Description of problem:
Anaconda installer chooses misleading names for logical volumes, resuling in names like
/dev/VolGroup00/LogVol01 which maps to /dev/mapper/VolGroup00-LogVol01
The use of the name LogVol suggests that it is a log volume, not a logical volume.
I suspect that this will cause confusion for people who administer other unixes as well as FC4.
The initials pv, vg, and lv are much more appropriate,
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install FC4 using all defaults
Actual Results: Ended up with misleading device names
Expected Results: It would have been nice to have the following:
This report targets the FC3 or FC4 products, which have now been EOL'd.
Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?
requested by Jams Antill
(In reply to comment #1)
> This report targets the FC3 or FC4 products, which have now been EOL'd.
> Could you please check that it still applies to a current Fedora release, and
> either update the target product or close it ?
The naming convention described above is still in use in rawhide as of today
(early F9 vintage). The Version field seems correct as "rawhide", nothing to
update there. Just stating the obvious to kick this out of NEEDINFO.
I have never heard of anyone thinking LogVol referred to a volume full of logs
instead of a logical volume. Anyone halfway familiar with the technology should
know what it means, and newcomers should be able to figure it out - after all,
"logical" is even in the name.
I believe you have not supported Linux LVM alongside other UNIX LVM technologies
(like AIX LVM, Solaris SDM, Veritas, etc) - what would you know about being
"half-familiar" with LVM?
Here's an excerpt from an AIX rootvg:
[root@xxxx] # lsvg -l rootvg
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
hd5 boot 1 2 2 closed/syncd N/A
hd6 paging 128 256 2 open/syncd N/A
hd8 jfs2log 1 2 2 open/syncd N/A
hd4 jfs2 1 2 2 open/syncd /
hd2 jfs2 19 38 2 open/syncd /usr
hd9var jfs2 8 16 2 open/syncd /var
hd3 jfs2 8 16 2 open/syncd /tmp
hd1 jfs2 1 2 2 open/syncd /home
hd10opt jfs2 24 48 2 open/syncd /opt
fwdump jfs2 3 6 2 open/syncd /var/adm/ras/platform
lg_dumplv sysdump 8 16 2 open/syncd N/A
auditlv jfs2 1 2 2 closed/syncd /audit
mksysblv jfs2 40 80 2 open/syncd /local/mksysb
loglv02 jfslog 1 1 1 closed/syncd N/A
Please note the default use of loglvXX for JFS journal log volumes, used instead
of in-line logs, found on many a newer journalled filesystem.
The point that I was trying to make was that the use of LogVol had different
meanings within the LVM world. Any filesystem which employs journalling will
have a journal log, which is either kept in-line on the same logical volume or
on a separate volume, called a "LogVol"ume.
Please review some LINUX journalled filesystem mkfs commands, such as
mkreiserfs' -j option, and mke2fs' -O option to specify a separate log volume
for performance reasons.
I suggest the annotation of "lv" should be used for logical volumes, rather than
"logvol", which would then allow Fedora/Linux LVM to be synonymous with almost
every other LVM implementation in use.
It's not our job to re-invent the wheel, but it helps if it's kept round in
shape, like all other wheels, so everyone knows what the wheel is and what it