[master/rhel7-branch] DASD storage re-write, take III

Samantha N. Bueno sbueno+anaconda at redhat.com
Thu Feb 27 14:17:49 UTC 2014


On Wed, Feb 26, 2014 at 10:31:24AM +0100, Vratislav Podzimek wrote:
> On Wed, 2014-02-26 at 00:07 -0500, Samantha N. Bueno wrote:
> > This now includes fixes from the second review. I had some residual
> > issues with thread handling and updating of the GUI spoke status as
> > well (that I didn't fully realize until after I posted my last set), and
> > those issues are fixed.
> > 
> > Just so things are clear, I've created four delightful and exciting
> > screencasts for anyone interested, so get your popcorn ready:
> > 
> > [graphical install]
> > http://sbueno.fedorapeople.org/1001070-graphical-20140225.webm
> > 
> > [graphical install w/zerombr in ks]
> > http://sbueno.fedorapeople.org/1001070-graphical-zerombr-20140225.webm
> > 
> > [text install]
> > http://sbueno.fedorapeople.org/1001070-text-20140225.webm
> > 
> > [text install w/zerombr in ks]
> > http://sbueno.fedorapeople.org/1001070-text-zerombr-20140225.webm
> From my perspective, these patches are good to go after doing few local
> changes fixing the neatpicks. Thanks for working on this so hard!

Great! Didn't want to respond to each message individually since they
were so small, but I've applied all your suggestions. Thanks very much
for the reviews. Re: this one piece though--

> > @@ -357,6 +365,10 @@ class StorageSpoke(NormalSpoke, StorageChecker):             
> >      def _doExecute(self):                                                        
> >          self._ready = False                                                      
> >          hubQ.send_not_ready(self.__class__.__name__)                             
> > +        # ugly and stupid, but on the off-chance dasdfmt is running,
> > we can't    
> > +        # proceed further with this                                              
> > +        while threadMgr.get(constants.THREAD_DASDFMT):                           
> > +            continue                                                             
> Is there any reason for doing this busy wait instead of calling                     
> threadMgr.wait(constants.THREAD_DASDFMT)? I believe the result would be             
> the same.

The only reason I do that is to avoid directly calling THREAD_DASDFMT to
try and reduce the UI freezing. I guess it is kind of the same though
since it is constantly checking the thread. I can't seem to come up
with a better way though. That is my only residual issue with this patch
set though.

Regardless, as there's some discussion over these patches in bz#1064423,
I'm not going to push these yet until that's resolved.

I know some folks from IBM watch this list, but I'm Cc'ing Peter
Oberparleiter just in case since I'd really like confirmation-- Is
there any potential risk of data loss for running dasdfmt on a cpfmtxa
formatted DASD? My understanding has always been that if a DASD has been
formatted with cpfmtxa, there is nothing on it, and thus no risk of data
loss. So I don't see that it should be necessary to warn a user before
running dasdfmt.
Obviously anyone else who watches this list and is knowledgeable in the
s390x realm, feel free to give input as well if you know. :)

Samantha


More information about the anaconda-patches mailing list