Bug 134638

Summary: RFE: Installer support for creating new LVs with non-linear segment types
Product: [Fedora] Fedora Reporter: Neal Becker <ndbecker2>
Component: anacondaAssignee: Vratislav Podzimek <vpodzime>
Status: ASSIGNED --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: agk, anaconda-maint-list, bmarzins, bmr, bos, bugzilla.redhat, curtis, djuran, dlehman, dshea, dwysocha, g.kaviyarasu, goeran, heinzm, jgranado, jiaqiang.a.zhang, jonathan, lvm-team, maurizio.antillon, mkolman, msnitzer, prajnoha, prockai, sbueno, triage, vanmeeuwen+fedora, zkabelac
Target Milestone: ---Keywords: FutureFeature, Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-12-10 16:48:10 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
The updates.img for the files
none
The diff
none
diff
none
Some comments on what was done. none

Description Neal Becker 2004-10-05 07:47:12 EDT
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:
Always

Steps to Reproduce:
1.install
2.
3.
    

Additional info:
Comment 1 Christian Iseli 2007-01-22 06:37:06 EST
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 ?

Thanks.
Comment 2 David Juran 2007-01-22 10:21:17 EST
Still no option to create a striped LV in the FC6 installer.
Comment 3 Neal Becker 2007-01-22 10:24:51 EST
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 10:38:15 EST
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 00:16:51 EST
*** Bug 223673 has been marked as a duplicate of this bug. ***
Comment 6 Marc Bejarano 2007-03-05 00:57:37 EST
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 11:22:18 EST
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 11:26:01 EST
Created attachment 149349 [details]
The updates.img for the files
Comment 9 Joel Andres Granados 2007-03-06 11:32:56 EST
Created attachment 149352 [details]
The diff
Comment 10 David Juran 2007-03-08 08:32:59 EST
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 04:31:23 EST
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-13 21:49:36 EDT
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 13:26:14 EDT
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 13:31:57 EDT
Created attachment 150144 [details]
diff
Comment 15 Joel Andres Granados 2007-03-15 13:34:21 EDT
Created attachment 150145 [details]
Some comments on what was done.
Comment 16 Bug Zapper 2008-04-03 21:51:10 EDT
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.
http://fedoraproject.org/wiki/LifeCycle/EOL

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:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

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 04:44:20 EDT
The functionality is still missing in the Fedora 9 beta, therefore switching to
rawhide.
Comment 18 Andy Lindeberg 2008-12-10 16:48:10 EST
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-20 20:29:35 EST
(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 12:18:09 EST
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}'`
  stripesizeK=128
  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 00:53:15 EDT
andy: are you refusing to reopen or are you just not seeing these requests?
Comment 22 Marc Bejarano 2009-04-23 17:42:22 EDT
sent andy email.  maybe he's not keeping up on bugmail?
Comment 23 Peter Jones 2009-04-27 11:14:54 EDT
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 11:26:58 EDT
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 14:26:42 EDT
*** Bug 506336 has been marked as a duplicate of this bug. ***
Comment 27 Alasdair Kergon 2010-04-27 09:49:30 EDT
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 16:05:18 EDT
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 17:21:00 EDT
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 10:57:56 EST
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 12:42:30 EST
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 15:17:45 EST
I want to install fedora (anaconda) using lvm striping.  Is this proposal compatible with that use case?
Comment 33 Alasdair Kergon 2011-02-11 15:25:30 EST
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 16:18:14 EST
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 16:23:43 EST
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 14:01:08 EDT
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 07:04:37 EDT
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 02:41:06 EDT
(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,
Jiaqiang
Comment 39 David Lehman 2013-11-06 15:35:56 EST
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 15:44:58 EST
hi david,

has there been any progress on this?  is it blocked by some other work?
Comment 41 David Lehman 2015-03-09 14:56:45 EDT
There has been no progress on this due to other work having higher priority.