Bug 134638 - RFE: Installer support for creating new LVs with non-linear segment types
Summary: RFE: Installer support for creating new LVs with non-linear segment types
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: anaconda-maint
QA Contact: Fedora Extras Quality Assurance
Whiteboard: bzcl34nup
: 223673 506336 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2004-10-05 11:47 UTC by Neal Becker
Modified: 2023-08-02 02:20 UTC (History)
26 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2008-12-10 21:48:10 UTC
Type: ---

Attachments (Terms of Use)
The updates.img for the files (68.00 KB, application/octet-stream)
2007-03-06 16:26 UTC, Joel Andres Granados
no flags Details
The diff (46.00 KB, text/plain)
2007-03-06 16:32 UTC, Joel Andres Granados
no flags Details
diff (23.14 KB, text/plain)
2007-03-15 17:31 UTC, Joel Andres Granados
no flags Details
Some comments on what was done. (4.35 KB, text/plain)
2007-03-15 17:34 UTC, Joel Andres Granados
no flags Details

Description Neal Becker 2004-10-05 11:47:12 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.3; Linux) (KHTML, like Gecko)

Description of problem:
anaconda allows creation of lvm, but there is no option for striping.  

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Additional info:

Comment 1 Christian Iseli 2007-01-22 11:37:06 UTC
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 ?


Comment 2 David Juran 2007-01-22 15:21:17 UTC
Still no option to create a striped LV in the FC6 installer.

Comment 3 Neal Becker 2007-01-22 15:24:51 UTC
Really?  I thought that was the default behavior.  Isn't there an option in 
the gui for an extent size, or something like that?  

Comment 4 David Juran 2007-01-22 15:38:15 UTC
No, I just checked and the default behaviour is to create a linear volume. There
is an option for setting the PE size, but no option for setting the stripe size
or number of stripes. 

Comment 5 Curtis Doty 2007-02-17 05:16:51 UTC
*** Bug 223673 has been marked as a duplicate of this bug. ***

Comment 6 Marc Bejarano 2007-03-05 05:57:37 UTC
neal (or somebody else with appropriate bits): could you change the summary to
reflect the fact that we're talking about disk druid here?  bug 208797 has a
better summary, imo.

Comment 7 Joel Andres Granados 2007-03-06 16:22:18 UTC
Added some striped functionality to the FC6 installation gui.  It only works for
graphical installation.  It looks good for most of my test cases, though it has
some strange behavior for some situations:
1. when the pe size is changed after the lv are created the installation might fail.
2. When editing prexisting lv it can present some unwanted behavior.
3. There might be more.

If all the logical volumes in a preexisting vg are new the gui seems to not
complain.  If the volume group is new the installer does not complain at all either.
There was a short discussion in the anaconda list about the relevance of striped
lvs being exposed in the installation gui.  It was argued that it will be fairly
complex to expose the user to the striped configuration and an option in the
kickstart file would be a lot better.
Additionally the patch introduces a lot of changes and will most likely
introduce more bugs than what it solves.  I will post it anyway to, perhaps,
have a temporary workaround to the issue.
I will attach the updates image.

Comment 8 Joel Andres Granados 2007-03-06 16:26:01 UTC
Created attachment 149349 [details]
The updates.img for the files

Comment 9 Joel Andres Granados 2007-03-06 16:32:56 UTC
Created attachment 149352 [details]
The diff

Comment 10 David Juran 2007-03-08 13:32:59 UTC
I'm not sure how much this would help the complexity of this problem, but one
way of making this simpler would be not to make any GUI changes at all but
instead just create a striped LV by default if the VG spans over more then one
PV. Wouldn't that make much more sense then making it linear? 

Comment 11 Joel Andres Granados 2007-03-09 09:31:23 UTC
I think the ideal would be to introduce a mechanism that lets the user decide
how he wants his lvm partitions.  This wouldn't necessarily mean a change in the
gui but must include a default behavior (could be the one you propose) and a way
to change the default.  So if I have a VG with 3 PV I can make a striped LV with
2 of the PV and second LV with the one that is left (the default behavior beging
two LV with 3 stripes).
I'm thinking on changing the kickstart code instead of the gui code.  This was
actually proposed by Jeremy Katz and I think its the best way to go.  In this
way an unexperienced user can gui install without knowing much about lvm and an
experienced user can use kickstart to modifiy his lvms.

Comment 12 Marc Bejarano 2007-03-14 01:49:36 UTC
experienced users use the GUI sometimes, too :P  it may not be a high priority
once you have kickstart support going, but i don that that disk druid should be
striping-aware in it's LVM GUI.

Comment 13 Joel Andres Granados 2007-03-15 17:26:14 UTC
For now the patch includes --stripedevs and --stripesize options 
--stripedevs receives a string of "," separated devices (pv.#,pv.#...)
--stripesize recieves an int identifying the stripe size in KB. (defauls to 2048)
The lv will be striped when the stripedevs is specified, if the stripedevs is
specified and the stripesize isnot, stripe size will default to 2048 KB.  If
stripesize is specified and stripedevs is not, stripesize will be ignored.

attached are the diffs and some additional comments.

Comment 14 Joel Andres Granados 2007-03-15 17:31:57 UTC
Created attachment 150144 [details]

Comment 15 Joel Andres Granados 2007-03-15 17:34:21 UTC
Created attachment 150145 [details]
Some comments on what was done.

Comment 16 Bug Zapper 2008-04-04 01:51:10 UTC
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers

Comment 17 David Juran 2008-04-15 08:44:20 UTC
The functionality is still missing in the Fedora 9 beta, therefore switching to

Comment 18 Andy Lindeberg 2008-12-10 21:48:10 UTC
It's highly unlikely that we'll include this. Joel has posted a patch, so anybody who feels strongly about the issue can use it themselves. If someone can make a compelling case as to why we should do this, we'll consider changing our minds, but until, CLOSED WONTFIX.

Comment 19 Marc Bejarano 2009-01-21 01:29:35 UTC
(In reply to comment #18)
> If someone
> can make a compelling case as to why we should do this, we'll consider changing
> our minds

hi, andy.  the best reason that comes to mind for me is consistency.  why allow some RAID levels and not others?  since we already have a patch to enhance functionality, why not include it?

Comment 20 Curtis Doty 2009-02-14 17:18:09 UTC
Compelling reason #1: Creating an LVM strip in %post is quite ugly:

  extents=`lvm pvs --noheadings -o pv_pe_count /dev/sd{b,i,c,j,d,k} |awk '{tot+=$1}END{print tot}'`
  lvm lvcreate -l$extents -nbar -I$stripesizeK -i2 foo /dev/sd{b,i,c,j,d,k}

Compelling reason #2: You can't do this for any system fs such as / or /usr.

Please re-open.

Comment 21 Marc Bejarano 2009-04-15 04:53:15 UTC
andy: are you refusing to reopen or are you just not seeing these requests?

Comment 22 Marc Bejarano 2009-04-23 21:42:22 UTC
sent andy email.  maybe he's not keeping up on bugmail?

Comment 23 Peter Jones 2009-04-27 15:14:54 UTC
I really do think we should be using striping instead of linear when a volume group spans multiple physical volumes, but I don't think this policy belongs in anaconda.  This should be something the lvm tools do by default.

Comment 24 Bryn M. Reeves 2009-04-27 15:26:58 UTC
Do we really want to do that automatically? For end-user systems it is probably not what the user expects or wants and has the potential to make recovery from disk failures more difficult.

Giving the user the ability to stripe if they want to seems reasonable. Forcing it on all lvm users who have more than one disk does not.

Comment 25 Andy Lindeberg 2009-06-16 18:26:42 UTC
*** Bug 506336 has been marked as a duplicate of this bug. ***

Comment 27 Alasdair Kergon 2010-04-27 13:49:30 UTC
So this splits into two.

(1) Add an option to lvm.conf that allows for striping by default instead of always having to specify it on the command line.

(2) Add a configuration option to anaconda that allows people to opt into this new policy and which would use it during installation and set it in lvm.conf as the default.   I agree with Bryn that it would not be sensible to make it default behaviour.

But for (1): How many stripes?  A fixed number?  Maximum possible?  If you've 1000 disks would you really benefit from 1000 stripes?  What about lvextend?  Would it use its current default or would it take account of the new policy or would it need to remember what policy was used last time space was added to the LV?  Do these problems negate any benefit from having a default?

Comment 28 Marc Bejarano 2010-04-27 20:05:18 UTC
hi, alasdair.

i think the default should benefit the most number of people without causing disaster for the minority.  i don't think there are many users who have so many disks that striping them (as opposed to a linear default) wouldn't be what they want.  those that do likely have high budgets and high in-house expertise and can handle changing the default to suit their needs.

so i would vote for turning on striping with the maximum possible by default for all with the ability to opt out in anaconda.

re: lvextend, in the absence of numbers proving otherwise, i'd guess many more people would gain from having a better default at install time than would lose from more complexity later on.  why not start here?

Comment 29 Alasdair Kergon 2010-04-27 21:21:00 UTC
The default behaviour has to be satisfactory for all users.  There are also choices in defining fallback behaviour - how do 'variable' numbers of stripes interact with the existing allocation policies?

And if I have 5 disks with different amounts of free space on each:  I try striping across all 5 but it doesn't fit.  Do I then try 4?  Then 3, 2 before falling back to linear?  Or do I stripe as much as I can 5-way, then try to find the remaining space 4-way, then what still remains, 3-way etc.?

Striping offers some people (not everyone) improved performance at the cost of making data recoverability useless for most people.  The default option must err on the side of better recoverability.  People who have already taken measures to protect against data loss (mirrors, frequent backups) or whose data has no special value (e.g. installations that are easily recreated) can opt for 'better performance'.

Comment 30 Floris 2011-02-07 15:57:56 UTC
Any progress update on this 2004 feature request?

LVM striping has become much more important recently, because LVM supports the TRIM/DISCARD functionality necessary to keep SSD performance optimal.
While mdraid currently does not.

Comment 31 Alasdair Kergon 2011-02-11 17:42:30 UTC
Well let's try to deal with this.

Firstly, this is an lvm2 bugzilla.  Any outstanding requests for changes to anaconda should move to a different bugzilla.

For LVM I propose:

1. An lvm.conf setting that will provide a default value for --stripes in commands that create new LVs.  Commands that *extend* existing LVs will ignore this and work as now, defaulting to continuing the striping of the last segment.
This will be useful for people who have lots of disks and always have a decent amount of disk space unallocated.

2. An allocation option for 'maximum reasonable' striping.  The details are still to be worked out, but the idea is to attempt always to stripe the data, adapting the number of stripes to the circumstances.

(I might split these across two bugzillas now.)

Comment 32 Neal Becker 2011-02-11 20:17:45 UTC
I want to install fedora (anaconda) using lvm striping.  Is this proposal compatible with that use case?

Comment 33 Alasdair Kergon 2011-02-11 20:25:30 UTC
Yes - anaconda would then need to provide an option to enable the new corresponding lvm option.

Separately, a discussion is beginning about how to link anaconda and lvm better so anaconda doesn't have to second-guess how lvm will lay out the data.

Comment 34 Curtis Doty 2011-02-11 21:18:14 UTC
Where is that anaconda discussion? I've been successfully using an ugly-but-effective wrapper script around lvm (in kickstart %pre) that automagically implements various presumptions for when to auto-stripe and how many stripes to use.

Comment 35 Alasdair Kergon 2011-02-11 21:23:43 UTC
Face-to-face so far I think - I've not been directly involved yet nor seen any ideas in writing.  It needs putting onto another bugzilla.

Comment 36 Marc Bejarano 2012-05-30 18:01:08 UTC
pjones moved this from an anaconda bug to an lvm2 bug on 4/29/09.  IMO, that was a mistake.  this bug was opened as an anaconda bug and seems to me to be one.

alasdair: would mind putting it back to being an anaconda bug?

Comment 37 Zdenek Kabelac 2013-05-14 11:04:37 UTC
Moving this bug back to Anaconda, since it's the user who should decide the configuration of striping - it should not happen 'magically' behind the scene - there are users who wants to strip - and those who don't....

Comment 38 Jiaqiang 2013-09-05 06:41:06 UTC
(In reply to Curtis Doty from comment #34)
> Where is that anaconda discussion? I've been successfully using an
> ugly-but-effective wrapper script around lvm (in kickstart %pre) that
> automagically implements various presumptions for when to auto-stripe and
> how many stripes to use.

Hi Curtis Doty, 

is it possible to share your wrapper script around lvm ?

I'm try to do the strip within kickstart. I hope I borrow the idea from your script.

Best regards,

Comment 39 David Lehman 2013-11-06 20:35:56 UTC
Support for creation of LVs with various segment types is planned, but there is no target release. In anaconda's GUI, the segment types would be those that correspond with standard RAID levels and would be set for individual LVs the same way RAID level is set for individual MD arrays. This functionality would presumably also be added to kickstart's logvol command. The bulk of the work will be the backend, which will go into python-blivet.

Comment 40 Marc Bejarano 2015-03-02 20:44:58 UTC
hi david,

has there been any progress on this?  is it blocked by some other work?

Comment 41 David Lehman 2015-03-09 18:56:45 UTC
There has been no progress on this due to other work having higher priority.

Comment 43 Vladimír Slávik 2020-10-06 12:04:28 UTC
Assigned to mail list is nonsense, returning to new.

Comment 44 genjosholiday.com 2022-01-22 00:03:25 UTC Comment hidden (spam)
Comment 45 Fedora Admin user for bugzilla script actions 2023-07-26 12:05:05 UTC
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

Note You need to log in before you can comment on or make changes to this bug.