Bug 503912 - library for the Linux Storage Stack
Summary: library for the Linux Storage Stack
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: DeviceKit-disks
Version: 11
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: David Zeuthen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-06-03 10:49 UTC by Ritesh Raj Sarraf
Modified: 2013-03-06 03:58 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-06-28 12:47:54 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Ritesh Raj Sarraf 2009-06-03 10:49:36 UTC
Description of problem:

Currently, there are no tools/libraries to be able to reliably fiddle with the 
Full Storage Stack in Linux (SCSI + "DM - LVM/Multipath" + File System).

For example, I wanted to write a LUN Administration tool. which could be used 
to manage the storage stack. Idea was to be able to trigger an 
addition/deletion/rescan and see the changes reflected in the entire stack.

Steps required were (example, for deletion):
* Take input from user for the list of LUNs she wants to see deleted. This 
could be in the format of the target. Like: lunadm delete -h hostname -l 
/vol/vol1/lun1
* The script should then get the LUN ID from the target.
* It should then match the list of relevant SCSI devices.
* It should then see if those devices are in use by DM (Multipath/LVM/Crypt)
* It should see if the DM device is mounted.
* Then, do the trigger.
* Unmount the device.
* Dis-Associate the device from the DM layer.
* Delete the SCSI devices on the host OR simply delete the LUN on the target 
and trigger a SCSI rescan on the host.

These steps would reflect the correct changes.



Reasons why I want to do this:

* rescan-scsi is not complete. It'd only rescan the SCSI Bus. Past experiences 
have shown stale SCSI device entries. And in many cases, if the LUN goes offline 
(with no paths), and you are using DM-Multipath with "queue_if_no_path", you 
lose everything. The processes that do a read/write to that device will go  
into 'D' state, which till recently not even the kernel was able to kill. Thus 
leading you to a System Reset.

* Another reason why I want to use is is because the SCSI + DM stack is not 
rigorously tested for LUN addition/deletion. We do claim support for 1000+ 
devices, but how reliable has it been with frequent 1000 device addition and 
deletion. We have applications with that requirement, and they break very 
often during addition/deletion of LUNs.

* We'd want to have a library which can be used to cleanly dis-associate and delete a LUN, on request.

*Tomorrow we would have btrfs, which will have many new ideas about blocks, Volumes et cetera.
Anaconda libs, part of the installer, will definitely be implementing those.

* I see the pyblock and pyparted libs to be of great use if you can make them 
independent, so that we can write applications on top of a library which will 
always be maintained (since anaconda will always use it).
Currently it is very tightly tied to the requirements of anaconda and is not very well documented.

An off-proposal could also be to break the anaconda libs into separate libs to be used by other applications without having a dependency.

Some of the modules I can see are:
partedUtils, partRequests, autopart, dmraid, fsset, iscsi, lvm, partitions

Using libraries that anaconda uses would have many benefits.
* Maintenance (Anaconda uses it. So it sure will be maintained)

bdevid, which is currently a pre-req for pyblock, is packaged as part of mkinitrd. It could be separated.

Comment 1 Chris Lumens 2009-06-03 14:10:47 UTC
It looks like you haven't checked out the anaconda storage code in quite a while, as the partedUtils, partRequests, and other python modules within anaconda no longer exists.  The pyblock and pyparted rewrites are much more complete, too, and no longer tied so closely to what anaconda wants.

I'm not sure exactly where this bug belongs, but I am positive it's not in anaconda.  We could break out our new storage libraries a little bit if there's sufficient interest in making other components work with them.  We've been spending some time pushing things into lvm, dmraid, parted, etc. as necessary.

Comment 2 Bug Zapper 2009-06-09 17:01:35 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 3 Bug Zapper 2010-04-27 14:38:20 UTC
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 4 Bug Zapper 2010-06-28 12:47:54 UTC
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


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