[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