lvcreate cannot use more than 8 stripes

Bug #1675770 reported by bugproxy on 2017-03-24
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu on IBM z Systems
Undecided
Canonical Server Team
lvm2 (Ubuntu)
High
Christian Ehrhardt 

Bug Description

Trying to create a logical volume with 64 stripes. Get the error message
Using default stripesize 64.00 KiB.
  Only up to 8 stripes in striped supported currently
  Run `lvcreate --help' for more information

Problem fix available at : https://sourceware.org/git/?p=lvm2.git;a=commit;h=2fcbe34fe85fa57e1e2835dfba95fa21387377b6

---uname output---
Linux s42lp01 4.10.0-8-generic #10-Ubuntu SMP Mon Feb 13 14:06:04 UTC 2017 s390x s390x s390x GNU/Linux

Machine Type = z systems: Type 2964, Model 701 NC9

---Debugger---
A debugger is not configured

---Steps to Reproduce---
 lvcreate --extents "65536" --stripes "64" --name "LogVol00" vg00

Userspace tool common name: lvcreate
The userspace tool has the following bit modes: 64-bit
Userspace rpm: lvm2
Userspace tool obtained from project website: na

Already fixed upstream. Will this be integrated into Ubuntu?

bugproxy (bugproxy) on 2017-03-24
tags: added: architecture-s39064 bugnameltc-152891 severity-high targetmilestone-inin1704
Changed in ubuntu:
assignee: nobody → Skipper Bug Screeners (skipper-screen-team)
affects: ubuntu → lvm2 (Ubuntu)
tags: added: s390x
Changed in ubuntu-z-systems:
assignee: nobody → Canonical Server Team (canonical-server)

------- Comment From <email address hidden> 2017-03-24 09:22 EDT-------
IBM Bugzilla: BZ152891

To easily check this without an unlikely number of devices one can easily follow the path we use for quick tests, here modified for this case:

$ WORKDIR=$(mktemp -d)
$ for i in $(seq 1 64); do
$ dd bs=1M count=64 if=/dev/zero "of=${WORKDIR}/dev${i}"
$ sync
$ sudo losetup "/dev/loop${i}" "${WORKDIR}/dev${i}"
$ done
$ sudo vgcreate --verbose testvg /dev/loop[1-9]*
$ sudo lvcreate --extents "128" --stripes "64" --name testlv testvg

With that I could confirm zesty being affected and X/Y being ok.

Changed in lvm2 (Ubuntu):
status: New → Triaged
assignee: Skipper Bug Screeners (skipper-screen-team) → ChristianEhrhardt (paelzer)

Interestingly on 128xPVs with just 1 extend each (8MB PVs) it can create an '--extents "128"' LV.
Which should also match a stripes=128 setup.

But anyway, yes it is broken yes it needs a fix.

Changed in lvm2 (Ubuntu):
importance: Undecided → High

I provided a fix to test in the following ppa:
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2646

In my testing that worked up to 128 stripes again.

Subscribing sponsors as I can't upload LVM, could you take a look at it.
There are a few burnt version numbers involved up to
 https://launchpad.net/ubuntu/+source/lvm2/2.02.167-1ubuntu4 If I checked correctly.
None of these made it or - as it seems - are going to do so.
So I'm jumping at -ubuntu5 and kill the failed history.

For your convenience as it is a bileto ticket, so
- diff is at:
- sponsoring can be done via publish on: https://bileto.ubuntu.com/#/ticket/2646

Changed in ubuntu-z-systems:
status: New → Triaged
Dimitri John Ledkov (xnox) wrote :

The diff is a bit noisy cosmetically due to changelog entries for ...4 and ...3 uploads which have been deleted from the archive. I would drop those, and simply have 2.02.167-1ubuntu5 entry above the 2.02.167-1ubuntu2 entry.

The patch / cherrypick looks fine to be sponsored as is, otherwise.

On Mon, Mar 27, 2017 at 1:01 PM, Dimitri John Ledkov <<email address hidden>
> wrote:

> The diff is a bit noisy cosmetically due to changelog entries for ...4
> and ...3 uploads which have been deleted from the archive. I would drop
> those, and simply have 2.02.167-1ubuntu5 entry above the
> 2.02.167-1ubuntu2 entry.
>

That was why I directly pointed to it in my bug update.
I thought I'm obliged to do so - that is what I have seen in the past.
But if I can just skip the old pieces that certainly makes things easier.
I can without any other change do so with an ubuntu6 upload to the same ppa.

> The patch / cherrypick looks fine to be sponsored as is, otherwise.
>

Thanks for the check.
I'll update shortly when the cleaner one is in the ppa.

Dimitri John Ledkov (xnox) wrote :

Well, the changelog must reflect the changes that are actually in the package. E.g. one can keep those changes in but then state "Reverted upload so and so because foo and bar." but it gets messy. As far as I can see those uploads were actual mistakes not inteded for the archive at all and we did not release them, thus it's best to keep changelog readable and for the package to contain what the changelog claims it has.

Dimitri John Ledkov (xnox) wrote :

Yeap the new package is much better, from human clarity point of view.

Thanks for clarifying Dimitri!

That said, new cleaned upload diff at
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-2646/2017-03-27_13:18:01/zesty_lvm2_content.diff

The ppa is rebuilding, but since other than changelog it is the same as the former upload I'd expect the dep8s and such to all work again.

Changed in lvm2 (Ubuntu):
status: Triaged → Fix Committed
Changed in ubuntu-z-systems:
status: Triaged → In Progress

The tests in proposed were mostly good except those of docker.io.
But those issues are unrelated (local to docker.io).
The issues seem to got fixed, please retrigger the tests to pick up testing against the newer docker.io and pass.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package lvm2 - 2.02.167-1ubuntu5

---------------
lvm2 (2.02.167-1ubuntu5) zesty; urgency=medium

  * d/p/fix-strips-limit.patch: Fix regression limiting number of
    stripes to 8 (LP: #1675770)

 -- Christian Ehrhardt <email address hidden> Mon, 27 Mar 2017 09:23:51 +0200

Changed in lvm2 (Ubuntu):
status: Fix Committed → Fix Released
Changed in ubuntu-z-systems:
status: In Progress → Fix Released

------- Comment From <email address hidden> 2017-04-04 11:03 EDT-------
Verified with zesty and package lvm2 - 2.02.167-1ubuntu5. Works fine now. Thanks a lot for the quick fix!

bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2017-04-04 11:11 EDT-------
IBM bugzilla Status -> Closed after verification. If a problem will be detected by docker.io and new bugzilla will be created....

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers