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

Peter Oberparleiter oberpar at linux.vnet.ibm.com
Mon Mar 3 10:09:31 UTC 2014


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.

-- 
Peter Oberparleiter
Linux on System z Development - IBM Germany



More information about the anaconda-patches mailing list