|
Bugzilla – Full Text Bug Listing |
| Summary: | vgchange notes availability of --alloc AllocationPolicy but doesn't document it | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Jon Nelson <jnelson-suse> |
| Component: | Basesystem | Assignee: | zhen ren <zren> |
| Status: | RESOLVED WONTFIX | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | ||
| Version: | Leap 42.2 | ||
| Target Milestone: | Leap 42.2 | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
Has anybody had time to look at this? It's not a huge deal but it's also probably very easy to fix. Still a problem as of 12.1 Beta 1. Still an issue 7 years later with LEAP 42.2. :-( (In reply to Jon Nelson from comment #3) > Still an issue 7 years later with LEAP 42.2. > > :-( Sorry to see things like this. Thanks for your report, indeed. You can find information about "alloc policy" from 'man lvm': === --alloc {anywhere|contiguous|cling|inherit|normal} Selects the allocation policy when a command needs to allocate Physical Extents from the Vol- ume Group. Each Volume Group and Logical Volume has an allocation policy defined. The default for a Volume Group is normal which applies common-sense rules such as not placing parallel stripes on the same Physical Volume. The default for a Logical Volume is inherit which applies the same policy as for the Volume Group. These policies can be changed using lvchange(8) and vgchange(8) or overridden on the command line of any command that performs allocation. The contiguous policy requires that new Physical Extents be placed adjacent to existing Physical Extents. The cling policy places new Physical Extents on the same Physical Volume as existing Physical Extents in the same stripe of the Logical Volume. If there are sufficient free Physical Extents to satisfy an allocation request but normal doesn't use them, anywhere will - even if that reduces performance by placing two stripes on the same Physical Volume. === Those information has been added in vgcreate manpage by upstream. I can queue it for the next update if you like:-) (In reply to Jon Nelson from comment #1) > Has anybody had time to look at this? It's not a huge deal but it's also > probably very easy to fix. BTW, it would be great to see such easy-fix from you:-) because, maybe, someone else doesn't care defects like this, hah. Hi Jon, I have accepted your request for factory: https://build.opensuse.org/request/show/487889 Do you still want that manpage fix for openSUSE leap42.{1|2}? I haven't had a chance to test the update in 42.2, and there is some risk there. I don't think the benefit outweighs the potential costs, so no: let's let this go to factory (and tumbleweed?) (In reply to Jon Nelson from comment #9) > I haven't had a chance to test the update in 42.2, and there is some risk > there. It won't help to upgrade to 42.2 with respect to this issue. What we need is a patch for it. > I don't think the benefit outweighs the potential costs, so no: Yes, I think so:-) As a workaround, we can refer to `man lvm` to get information about '--alloc' as comment#5. let's let > this go to factory (and tumbleweed?) Thanks. Firstly, the request will go to factory. After staged for a while, it will be pulled into tumbleweed. So, closed with 'WONTFIX'. |
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100204 SUSE/3.5.8-0.1.1 Firefox/3.5.8 From the vgchange manpage: vgchange [--addtag Tag] [--alloc AllocationPolicy] [-A|--autobackup {y|n}] [-a|--available [e|l] {y|n}] [--monitor {y|n}] [-c|--clustered {y|n}] [-u|--uuid] [-d|--debug] [--deltag Tag] [-h|--help] [--ignorelockingfailure] [--ignoremonitoring] [-l|--logicalvolume MaxLogicalVolumes] [-p|--maxphysicalvolumes MaxPhysicalVolumes] [-P|--partial] [-s|--physicalextentsize Physi- calExtentSize[kKmMgGtT]] [--refresh] [-t|--test] [-v|--verbose] [--version] [-x|--resizeable {y|n}] [VolumeGroupName...] However, that is the only time 'alloc' is mentioned. Are docs missing or is the synopsis wrong? Reproducible: Always Steps to Reproduce: 1. 2. 3.