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