Red Hat Bugzilla – Bug 870376
RFE: asynchronous storage jobs
Last modified: 2015-09-28 16:25:09 EDT
Currently, the Anaconda storage module (Blivet) performs all actions synchronously, e.g. starts mkfs.ext3 and blocks the application until it is done.
Long duration jobs should be started in separate processes asynchronously and application should be notified when they end (e.g. via callback).
Sure, the application can fork itself, but forking whole Anaconda while one part starts mkfs.ext3 and the second part serves other application requests does not seem to be a good idea.
I've talked with dlehman and we agreed on this solution:
- application has one thread (T1) to read stuff from DeviceTree
- application puts actions to the device tree in T1, but does not execute them
- more actions can wait for execution in (application managed?) queue
- application starts new thread (T2) and executes the queued actions
- the actions are executed sequentially, one at a time
- it's up to the application to preserve order of the actions
- (in future) the application may create multiple threads and do more actions in parallel, if they do not influence each other
- the devicetree shows the *target* state, all the devices look like they were already created/removed/changes
- with appropriate properties that clearly distinguish that the device does not exist yet
- (this is already implemented)
- if an queued action fails, application determines the consequences
- in the first release, it just wipes the queue and re-reads devicetree
- application adds a new action to the device tree in T1
- at the same time, T2 finishes an action and updates the device tree with it
- (in future) async event comes at the same time that a device was changed/added/removed (there is separate bug for async event, just keep in mind it may be another source of race conditions)
Most of the functionality is probably already implemented in Blivet. This bug is about further investigation if everything is safe and/or how to make it safe in Blivet.
Asynchronous device actions are high priority for OpenLMI, we do not want to wait for mkfs on 1TB drive :) and block everything until it finishes.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.