Bug 134638

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.

Still no option to create a striped LV in the FC6 installer.

Really?  I thought that was the default behavior.  Isn't there an option in 
the gui for an extent size, or something like that?  

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. 

*** Bug 223673 has been marked as a duplicate of this bug. ***

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.

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.

Created attachment 149349 [details]
The updates.img for the files

Created attachment 149352 [details]
The diff

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? 

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.

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.

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.

Created attachment 150144 [details]
diff

Created attachment 150145 [details]
Some comments on what was done.

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

The functionality is still missing in the Fedora 9 beta, therefore switching to
rawhide.

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.

(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?

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.

andy: are you refusing to reopen or are you just not seeing these requests?

sent andy email.  maybe he's not keeping up on bugmail?

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.

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.

*** Bug 506336 has been marked as a duplicate of this bug. ***

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?

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?

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'.

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.

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.)

I want to install fedora (anaconda) using lvm striping.  Is this proposal compatible with that use case?

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.

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.

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.

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?

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....

(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

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.

hi david,

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

There has been no progress on this due to other work having higher priority.

Assigned to mail list is nonsense, returning to new.

This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.