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

Samantha N. Bueno sbueno+anaconda at redhat.com
Mon Mar 3 13:48:18 UTC 2014


On Mon, Mar 03, 2014 at 11:09:31AM +0100, Peter Oberparleiter wrote:
> On 28.02.2014 10:53, Peter Oberparleiter wrote:
> > On 27.02.2014 15:17, Samantha N. Bueno wrote:
> >> 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.
> > 
> > I'm not sure I have enough context information to fully answer this
> > question. As you stated, z/VM's CPFMTXA will format the DASD, usually
> > clearing all data in the process, just like dasdfmt will do. I don't
> > know where data loss beyond the clearing of the DASD would come in
> > here...
> > 
> > 
> >> Obviously anyone else who watches this list and is knowledgeable in the
> >> s390x realm, feel free to give input as well if you know. :)
> 
> Here's some more information from our DASD expert Stefan Weinhuber:
> 
> cpfmtxa is a z/VM tool that is usually used to prepare a disk for use
> with z/VM, e.g. as spool device or to store minidisks. Some people use
> it on DASDs they have previously used with other operating systems, to
> make sure that there is no old format left. A disk formatted with
> cpfmtxa contains a format that is not recognized and supported by Linux,
> but it does contain a format, and may contain data.

Thanks, that's actually very helpful. Due to the 'may contain data'
possibility, I'll add the 'format' button back in instead of just
auto-formatting selected DASDs then.

Thanks again to both of you.

Samantha


More information about the anaconda-patches mailing list