Hi Mauro, Thanks for this hint. But my script looked in the beginig like yours :-)
I have tried it out. CHCCWDEV -d gives sometime rc 256. and the fdasd rc: 65280 (Disk in use!). I added now retries: In case I have a nonzero rc I redo the command up to five times with a sleep of one second. Up to know the retry loop has to issue the commands only a second time to deliver an rc 0. This is what I don't like: "Hammering" the command into the system and hope it will work out. I used sync which might help for the fdasd problem after the dasdfmt. But I am nut sure yet. BTW: I have kernel 3.0.34-0.7-default active on my system. BR Florian On Mon, Jul 16, 2012 at 9:54 PM, Mauro Souza <[email protected]> wrote: > I usually put some sleeps and syncs along the way to give time to this > settle down: > dasdfmt -y -b 4096 -p -f /dev/dasdx > sleep 2 > sync > fdasd -a /dev/dasdx > sleep 2 > sync > mkfs.ext3 /dev/dasdx1 > > It works almost all the time. You could put some error checking routines > around, but I think this is simple enough to run without that. > Em 16/07/2012 15:45, "Florian Bilek" <[email protected]> escreveu: > > > Dear all, > > > > From time to time I am confronted with an weird problem with the > s390-tools > > which is really a PITA. > > > > I have a small script that should simply execute a dasdfmt afterwards a > > fdasd and finally a mkfs to prepare a new DASD. > > > > What happens is that after the dasdmft the fdasd gets sometimes the > > information that the disk is in use and gives an return code and the > script > > stops. > > > > This is results now in a kind of game to serialize those commands. > > > > In SLES 11 SP1 I could find a solution that after the dasdfmt I would > > disable the device (chccwdev -d xxxx) and enable it afterwards. There > was a > > wait of some seconds in between. > > > > Looking on the Internet I found a better way to circumvent the fixed > > waiting time: udevadm settle --timeout=60 --exit-if-exists=/dev/dasd > would > > wait till either there is a timeout or the device shows up in the /dev > > filesystem. > > > > Under SP2 I am facing again the problem since either a chccwdev -d xxxx > > brings now a device busy and delivers a return code or the fdasd returns > > that the device is busy. > > > > Is there a way to safely check if the device is not busy any more? > > > > That device is LINKED with W exclusively to the guest executing my > script. > > There is also no other activity on that specific device on this guest. > > > > I have the feeling that a new kernel brings sometimes back these > troubles. > > > > Is there a proper way to address this problem? > > > > Thank you very much in advance. > > > > -- > > Best regards > > > > Florian Bilek > > > > ---------------------------------------------------------------------- > > For LINUX-390 subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO LINUX-390 or > > visit > > http://www.marist.edu/htbin/wlvindex?LINUX-390 > > ---------------------------------------------------------------------- > > For more information on Linux on System z, visit > > http://wiki.linuxvm.org/ > > > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
