Re: dasdfmt slowness
What we do to speed dasdfmt up is to split the large dasd into smaller minidisks and join them by LVM. Then the individual minidisks can be formatted in parallel. This is easy to script with xargs, which has the parameter --max-procs that lets you specify the maximum number of worker processes to spawn. Tomas
Re: dasdfmt slowness
On 04.03.2014 00:18, Marcy Cortes wrote: Back Nov 2012 ... a long discussion ensued. On 08.11.2012 00:58, Marcy Cortes wrote: It takes about 42 minutes here to dasdfmt a volume with 65519 cylinders on it. It takes about 18 minutes to dd an already formatted volume over to a new one. It also takes about 19 minutes to fill it up with zeros by cat /dev/zero to it. Why does dasdfmt take so long? This is a known problem which is currently being investigated. Regards, Peter Oberparleiter Any progress in this area? Yes: Improvements have been made to both the dasdfmt tool and the Linux kernel to speed up the process of formatting a DASD. These changes are available upstream [1][2] (both are needed for an effect to become visible) and work is being done to get them integrated in upcoming distribution releases. The new code makes use of PAV and HyperPAV aliases, but can also provide a noticeable improvement without any aliases. Regards, Peter Oberparleiter [1] http://www.ibm.com/developerworks/linux/linux390/s390-tools-1.23.0.html [2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d42e17129b9f473386d67c6a6549c28bd0e2b52e -- Peter Oberparleiter Linux on System z Development - IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: dasdfmt slowness
I'm still of the opinion that the hardware guys need to step up. The fact that you have to go and do multitrack writes of count-key-data with zero filled records for the extent you're interested in seems like a huge waste of channel bandwidth and controller activity. Unlike the old days we're not really formatting anything. The ECKD smarts in the controller/device are using the Count/Key information it as metadata. Imagine rather than having to go through the pantomime of all these writes, interrupts, a delays you simply told the device: start-extent, end-extent, block size and let it do the dirty work itself. All that would be required would be that I/O plus another to write records 0-5 on track 0. I'm probably being too simplistic but there has to be a better way of doing things instead of going through the pretense of formatting. This is such a common task and one that will become more and more a pain in the rear as dynamic provisioning for cloud-like configurations become more prevalent, so it should be as trivial as possible. Neale On Mar 4, 2014, at 5:23 AM, Peter Oberparleiter wrote: On 04.03.2014 00:18, Marcy Cortes wrote: Back Nov 2012 ... a long discussion ensued. On 08.11.2012 00:58, Marcy Cortes wrote: It takes about 42 minutes here to dasdfmt a volume with 65519 cylinders on it. It takes about 18 minutes to dd an already formatted volume over to a new one. It also takes about 19 minutes to fill it up with zeros by cat /dev/zero to it. Why does dasdfmt take so long? This is a known problem which is currently being investigated. Regards, Peter Oberparleiter Any progress in this area? Yes: Improvements have been made to both the dasdfmt tool and the Linux kernel to speed up the process of formatting a DASD. These changes are available upstream [1][2] (both are needed for an effect to become visible) and work is being done to get them integrated in upcoming distribution releases. The new code makes use of PAV and HyperPAV aliases, but can also provide a noticeable improvement without any aliases. Regards, Peter Oberparleiter [1] http://www.ibm.com/developerworks/linux/linux390/s390-tools-1.23.0.html [2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d42e17129b9f473386d67c6a6549c28bd0e2b52e -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: dasdfmt slowness
If only I had the flashcopy feature! That's a good idea though! -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Berthold Gunreben Sent: Monday, March 03, 2014 11:47 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] dasdfmt slowness Hi Marcy, I have no idea, if this is being investigated. For myself, I found a different solution. You can dasdfmt one disk, and then do a flashcopy to all other disks of the same size that should be formatted. Hope this helps... Berthold On Mon, 3 Mar 2014 23:18:19 + Marcy Cortes marcy.d.cor...@wellsfargo.com wrote: Back Nov 2012 ... a long discussion ensued. On 08.11.2012 00:58, Marcy Cortes wrote: It takes about 42 minutes here to dasdfmt a volume with 65519 cylinders on it. It takes about 18 minutes to dd an already formatted volume over to a new one. It also takes about 19 minutes to fill it up with zeros by cat /dev/zero to it. Why does dasdfmt take so long? This is a known problem which is currently being investigated. Regards, Peter Oberparleiter Any progress in this area? Marcy -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/ -- -- Berthold Gunreben Build Service Team http://www.suse.de/ Maxfeldstr. 5 SUSE LINUX Products GmbH D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: dasdfmt slowness
Yay! Thanks! That's good news. -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Peter Oberparleiter Sent: Tuesday, March 04, 2014 2:23 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] dasdfmt slowness On 04.03.2014 00:18, Marcy Cortes wrote: Back Nov 2012 ... a long discussion ensued. On 08.11.2012 00:58, Marcy Cortes wrote: It takes about 42 minutes here to dasdfmt a volume with 65519 cylinders on it. It takes about 18 minutes to dd an already formatted volume over to a new one. It also takes about 19 minutes to fill it up with zeros by cat /dev/zero to it. Why does dasdfmt take so long? This is a known problem which is currently being investigated. Regards, Peter Oberparleiter Any progress in this area? Yes: Improvements have been made to both the dasdfmt tool and the Linux kernel to speed up the process of formatting a DASD. These changes are available upstream [1][2] (both are needed for an effect to become visible) and work is being done to get them integrated in upcoming distribution releases. The new code makes use of PAV and HyperPAV aliases, but can also provide a noticeable improvement without any aliases. Regards, Peter Oberparleiter [1] http://www.ibm.com/developerworks/linux/linux390/s390-tools-1.23.0.html [2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d42e17129b9f473386d67c6a6549c28bd0e2b52e -- Peter Oberparleiter Linux on System z Development - IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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 lists...@vm.marist.edu 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/
Re: dasdfmt slowness
I did discover that I can do a whole bunch of them in parallel, getting the i/o rates 4000k/sec or so seemingly without any effect to anyone else. When it’s a 1TB LVM, I don't want to split them any further, but waiting an hour or two so isn't as bad as doing them one at a time. Thanks for the xargs tip! Good idea! -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Pavelka, Tomas Sent: Tuesday, March 04, 2014 12:01 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] dasdfmt slowness What we do to speed dasdfmt up is to split the large dasd into smaller minidisks and join them by LVM. Then the individual minidisks can be formatted in parallel. This is easy to script with xargs, which has the parameter --max-procs that lets you specify the maximum number of worker processes to spawn. Tomas
Re: dasdfmt slowness
I'm still of the opinion that the hardware guys need to step up. The fact that you have to go and do multitrack writes of count-key-data with zero filled records for the extent you're interested in seems like a huge waste of channel bandwidth and controller activity. Unlike the old days we're not really formatting anything. The ECKD smarts in the controller/device are using the Count/Key information it as metadata. Imagine rather than having to go through the pantomime of all these writes, interrupts, a delays you simply told the device: start-extent, end-extent, block size and let it do the dirty work itself. All that would be required would be that I/O plus another to write records 0-5 on track 0. Leave the current code in place, but hook the flashcopy code to write a preformatted cylinder pattern, even if flashcopy is generally not available on the box. STK used to do this very elegantly in their copy-on-write code that built a disk as needed from a pool of blocks. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: dasdfmt slowness
Marcy, On my SLES 11-SP3 system, I can format a 65K cyl disk in a little over 12 minutes without PAV, etc. which is quite different from your 42 minutes number. Maybe this is somehow hardware related? systest:~ # time dasdfmt -f /dev/dasdk Please enter the blocksize of the formatting [4096]: Drive Geometry: 64550 Cylinders * 15 Heads = 968250 Tracks I am going to format the device /dev/dasdk in the following way: Device number of device : 0xfff Labelling device: yes Disk label : VOL1 Disk identifier : 0X0FFF Extent start (trk no) : 0 Extent end (trk no) : 968249 Compatible Disk Layout : yes Blocksize : 4096 --- ATTENTION! --- All data of that device will be lost. Type yes to continue, no will leave the disk untouched: yes Formatting the device. This may take a while (get yourself a coffee). Finished formatting the device. Rereading the partition table... ok real12m39.650s user0m0.051s sys 0m2.618s webml:~ # uname -a Linux systest 3.0.93-0.8-default #1 SMP Tue Aug 27 08:44:18 UTC 2013 (70ed288) s390x s390x s390x GNU/Linux -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy Cortes Sent: Tuesday, March 04, 2014 10:03 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: dasdfmt slowness I did discover that I can do a whole bunch of them in parallel, getting the i/o rates 4000k/sec or so seemingly without any effect to anyone else. When it’s a 1TB LVM, I don't want to split them any further, but waiting an hour or two so isn't as bad as doing them one at a time. Thanks for the xargs tip! Good idea! -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Pavelka, Tomas Sent: Tuesday, March 04, 2014 12:01 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] dasdfmt slowness What we do to speed dasdfmt up is to split the large dasd into smaller minidisks and join them by LVM. Then the individual minidisks can be formatted in parallel. This is easy to script with xargs, which has the parameter --max-procs that lets you specify the maximum number of worker processes to spawn. Tomas -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: dasdfmt slowness
I have no idea, if this is being investigated. For myself, I found a different solution. You can dasdfmt one disk, and then do a flashcopy to all other disks of the same size that should be formatted. The Cornell Minidisk Manager code lives again 8-)
Re: dasdfmt slowness
Well, that makes the most sense, but it would probably be serveral years before it gets on the floor and would then probably be only in the latest and greatest boxes. A SW solution is needed for the near term for the impatient and the ones with older HW. Marcy -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Neale Ferguson Sent: Tuesday, March 04, 2014 6:47 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] dasdfmt slowness I'm still of the opinion that the hardware guys need to step up. The fact that you have to go and do multitrack writes of count-key-data with zero filled records for the extent you're interested in seems like a huge waste of channel bandwidth and controller activity. Unlike the old days we're not really formatting anything. The ECKD smarts in the controller/device are using the Count/Key information it as metadata. Imagine rather than having to go through the pantomime of all these writes, interrupts, a delays you simply told the device: start-extent, end-extent, block size and let it do the dirty work itself. All that would be required would be that I/O plus another to write records 0-5 on track 0. I'm probably being too simplistic but there has to be a better way of doing things instead of going through the pretense of formatting. This is such a common task and one that will become more and more a pain in the rear as dynamic provisioning for cloud-like configurations become more prevalent, so it should be as trivial as possible. Neale On Mar 4, 2014, at 5:23 AM, Peter Oberparleiter wrote: On 04.03.2014 00:18, Marcy Cortes wrote: Back Nov 2012 ... a long discussion ensued. On 08.11.2012 00:58, Marcy Cortes wrote: It takes about 42 minutes here to dasdfmt a volume with 65519 cylinders on it. It takes about 18 minutes to dd an already formatted volume over to a new one. It also takes about 19 minutes to fill it up with zeros by cat /dev/zero to it. Why does dasdfmt take so long? This is a known problem which is currently being investigated. Regards, Peter Oberparleiter Any progress in this area? Yes: Improvements have been made to both the dasdfmt tool and the Linux kernel to speed up the process of formatting a DASD. These changes are available upstream [1][2] (both are needed for an effect to become visible) and work is being done to get them integrated in upcoming distribution releases. The new code makes use of PAV and HyperPAV aliases, but can also provide a noticeable improvement without any aliases. Regards, Peter Oberparleiter [1] http://www.ibm.com/developerworks/linux/linux390/s390-tools-1.23.0.htm l [2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/ ?id=d42e17129b9f473386d67c6a6549c28bd0e2b52e -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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 lists...@vm.marist.edu 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/
Re: dasdfmt slowness
It is in a way. It is way worse under PPRC replication. XRC replication probably isn't helping either. We do both. Marcy -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Aria Bamdad Sent: Tuesday, March 04, 2014 7:19 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] dasdfmt slowness Marcy, On my SLES 11-SP3 system, I can format a 65K cyl disk in a little over 12 minutes without PAV, etc. which is quite different from your 42 minutes number. Maybe this is somehow hardware related? systest:~ # time dasdfmt -f /dev/dasdk Please enter the blocksize of the formatting [4096]: Drive Geometry: 64550 Cylinders * 15 Heads = 968250 Tracks I am going to format the device /dev/dasdk in the following way: Device number of device : 0xfff Labelling device: yes Disk label : VOL1 Disk identifier : 0X0FFF Extent start (trk no) : 0 Extent end (trk no) : 968249 Compatible Disk Layout : yes Blocksize : 4096 --- ATTENTION! --- All data of that device will be lost. Type yes to continue, no will leave the disk untouched: yes Formatting the device. This may take a while (get yourself a coffee). Finished formatting the device. Rereading the partition table... ok real12m39.650s user0m0.051s sys 0m2.618s webml:~ # uname -a Linux systest 3.0.93-0.8-default #1 SMP Tue Aug 27 08:44:18 UTC 2013 (70ed288) s390x s390x s390x GNU/Linux -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy Cortes Sent: Tuesday, March 04, 2014 10:03 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: dasdfmt slowness I did discover that I can do a whole bunch of them in parallel, getting the i/o rates 4000k/sec or so seemingly without any effect to anyone else. When it’s a 1TB LVM, I don't want to split them any further, but waiting an hour or two so isn't as bad as doing them one at a time. Thanks for the xargs tip! Good idea! -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Pavelka, Tomas Sent: Tuesday, March 04, 2014 12:01 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] dasdfmt slowness What we do to speed dasdfmt up is to split the large dasd into smaller minidisks and join them by LVM. Then the individual minidisks can be formatted in parallel. This is easy to script with xargs, which has the parameter --max-procs that lets you specify the maximum number of worker processes to spawn. Tomas -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: dasdfmt slowness
I have a DIRMAINT exit around somewhere that I played with to run LXFMT to clean disks rather then the standard format. We also played with doing a flashcopy of Linux formatted disks, but ended up sticking with LXFMT and setting things up so that when a Linux guest got a new disk, it was already formatted with LXFMT. As with flashcopy, this is only useful if you use the same size disks and always hand out the same minidisk extent start/end. And you need to ensure DASD added to the Linux pool is already Linux formatted (I would define a minidisk on the new DASD and then do a DMDISK on it :) I do realize this is completely unrelated to dasdfmt being slow - but it did give us a method to do the formats in the 'background' and not require Linux to do a dasdfmt. Scott Rohling On Tue, Mar 4, 2014 at 7:00 AM, Marcy Cortes marcy.d.cor...@wellsfargo.comwrote: If only I had the flashcopy feature! That's a good idea though! -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Berthold Gunreben Sent: Monday, March 03, 2014 11:47 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] dasdfmt slowness Hi Marcy, I have no idea, if this is being investigated. For myself, I found a different solution. You can dasdfmt one disk, and then do a flashcopy to all other disks of the same size that should be formatted. Hope this helps... Berthold On Mon, 3 Mar 2014 23:18:19 + Marcy Cortes marcy.d.cor...@wellsfargo.com wrote: Back Nov 2012 ... a long discussion ensued. On 08.11.2012 00:58, Marcy Cortes wrote: It takes about 42 minutes here to dasdfmt a volume with 65519 cylinders on it. It takes about 18 minutes to dd an already formatted volume over to a new one. It also takes about 19 minutes to fill it up with zeros by cat /dev/zero to it. Why does dasdfmt take so long? This is a known problem which is currently being investigated. Regards, Peter Oberparleiter Any progress in this area? Marcy -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/ -- -- Berthold Gunreben Build Service Team http://www.suse.de/ Maxfeldstr. 5 SUSE LINUX Products GmbH D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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 lists...@vm.marist.edu 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/
Re: dasdfmt slowness
Not very familiar with either but is it possible to disable replication for the volume you are formatting while it is being formatted and then re-enable? If the bottleneck is in the replication, then speeding up the dasdfmt code may not be of much help. -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy Cortes Sent: Tuesday, March 04, 2014 10:36 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: dasdfmt slowness It is in a way. It is way worse under PPRC replication. XRC replication probably isn't helping either. We do both. Marcy -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Aria Bamdad Sent: Tuesday, March 04, 2014 7:19 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] dasdfmt slowness Marcy, On my SLES 11-SP3 system, I can format a 65K cyl disk in a little over 12 minutes without PAV, etc. which is quite different from your 42 minutes number. Maybe this is somehow hardware related? systest:~ # time dasdfmt -f /dev/dasdk Please enter the blocksize of the formatting [4096]: Drive Geometry: 64550 Cylinders * 15 Heads = 968250 Tracks I am going to format the device /dev/dasdk in the following way: Device number of device : 0xfff Labelling device: yes Disk label : VOL1 Disk identifier : 0X0FFF Extent start (trk no) : 0 Extent end (trk no) : 968249 Compatible Disk Layout : yes Blocksize : 4096 --- ATTENTION! --- All data of that device will be lost. Type yes to continue, no will leave the disk untouched: yes Formatting the device. This may take a while (get yourself a coffee). Finished formatting the device. Rereading the partition table... ok real12m39.650s user0m0.051s sys 0m2.618s webml:~ # uname -a Linux systest 3.0.93-0.8-default #1 SMP Tue Aug 27 08:44:18 UTC 2013 (70ed288) s390x s390x s390x GNU/Linux -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy Cortes Sent: Tuesday, March 04, 2014 10:03 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: dasdfmt slowness I did discover that I can do a whole bunch of them in parallel, getting the i/o rates 4000k/sec or so seemingly without any effect to anyone else. When it’s a 1TB LVM, I don't want to split them any further, but waiting an hour or two so isn't as bad as doing them one at a time. Thanks for the xargs tip! Good idea! -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Pavelka, Tomas Sent: Tuesday, March 04, 2014 12:01 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] dasdfmt slowness What we do to speed dasdfmt up is to split the large dasd into smaller minidisks and join them by LVM. Then the individual minidisks can be formatted in parallel. This is easy to script with xargs, which has the parameter --max-procs that lets you specify the maximum number of worker processes to spawn. Tomas -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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 lists...@vm.marist.edu 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/
Re: dasdfmt slowness
On 03/03/2014 06:18 PM, Marcy Cortes wrote: Why does dasdfmt take so long? Marcy -- Several options are available to you now, most immediate being to _take the low level formatting out of Linux_. You can ... * 'dasdfmt' a reference disk and then DDR that to all new disks, and 'fdasd -a' -or- * CMS FORMAT disks (either ref or on-demand) and stamp a 1 cyl worth of CDL magic -or- * CMS FORMAT and RESERVE (either ref or on-demand) -or- * CMS FORMAT disks (either ref or on-demand) and use it as-is The installer differentiates between low level and high level formatting, so you should be able to skip 'dasdfmt'. You still want high level where you'll use the disk as EXT2/3/4 or as a PV for use by LVM. Details follow. (Cut here if it's TL/DR.) The concept of low level formatting has gone away for most disk systems, but remains for ECKD. Linux (as with CMS and others) doesn't want to muck with tracks and records, but more efficiently uses pre-formatted same-sized blocks and a filesystem layered on top of that. Okay ... an exception ... real floppy disks are still track-and-record animals. (I'll avoid further sarcasm.) For ECKD, CMS FORMAT silently combines the two operations, lays out the tracks and records with 4K blocks (or other sizes if you wish) and then stamps an empty EDF filesystem on the disk. You can use CMS FORMAT to lay out 4K blocks which Linux will be happy to use. Except for RESERVED, it will destroy the EDF filesystem and put its own logic there (EXT*, PV for LVM, whatever). For FBA and EDEV and VDISK, CMS FORMAT silently skips the low level part and merely puts an EDF filesystem onto the media. Done! I imagine SAN and other FBA options are not available to you. Pity. So you will need to get those lovely empty 4K blocks out there somehow. The only reason CKD persists is because someone within IBM has fought to keep it alive in MVS space. There was a push, now thirty years ago, to get MVS to play FBA like CP, CMS, VSE, and others. Remember 3370? Died in the pooky playground. Last I heard, one DASD vendor offered FBA on the wire. (That is, w/o SAN, actual 3370 or 9336 channel programs. Woo hoo!) If your DASD systems are able, you can present FBA to Linux and there will be no low level formatting. All the benefit of EDEV but without the overhead. CDL complicates the low level task for the sake of compatibility with MVS. The only reason CDL exists is to present a funky first track where MVS can find a label and VTOC. CP and CMS manage to find a legit label w/o the block breakage. Go figure. (Okay, more sarcasm. Sorry.) If you don't need to share Linux content with MVS, then you don't need CDL. If you go other routes than CDL, your low level formatting is ... trivial. (Just slow when done by Linux.) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: dasdfmt slowness
Not really possible without an act of God (change req and in the wee hours of Sunday). I am pretty sure the replication team would veto that idea since they would have to do it and change all the configs. Things that write small blocks are particularly replication unfriendly (we learned that with channel extension and FOCUS in the 90s!). I suspect this is similar deal. -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Aria Bamdad Sent: Tuesday, March 04, 2014 7:50 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] dasdfmt slowness Not very familiar with either but is it possible to disable replication for the volume you are formatting while it is being formatted and then re-enable? If the bottleneck is in the replication, then speeding up the dasdfmt code may not be of much help. -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy Cortes Sent: Tuesday, March 04, 2014 10:36 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: dasdfmt slowness It is in a way. It is way worse under PPRC replication. XRC replication probably isn't helping either. We do both. Marcy -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Aria Bamdad Sent: Tuesday, March 04, 2014 7:19 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] dasdfmt slowness Marcy, On my SLES 11-SP3 system, I can format a 65K cyl disk in a little over 12 minutes without PAV, etc. which is quite different from your 42 minutes number. Maybe this is somehow hardware related? systest:~ # time dasdfmt -f /dev/dasdk Please enter the blocksize of the formatting [4096]: Drive Geometry: 64550 Cylinders * 15 Heads = 968250 Tracks I am going to format the device /dev/dasdk in the following way: Device number of device : 0xfff Labelling device: yes Disk label : VOL1 Disk identifier : 0X0FFF Extent start (trk no) : 0 Extent end (trk no) : 968249 Compatible Disk Layout : yes Blocksize : 4096 --- ATTENTION! --- All data of that device will be lost. Type yes to continue, no will leave the disk untouched: yes Formatting the device. This may take a while (get yourself a coffee). Finished formatting the device. Rereading the partition table... ok real12m39.650s user0m0.051s sys 0m2.618s webml:~ # uname -a Linux systest 3.0.93-0.8-default #1 SMP Tue Aug 27 08:44:18 UTC 2013 (70ed288) s390x s390x s390x GNU/Linux -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy Cortes Sent: Tuesday, March 04, 2014 10:03 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: dasdfmt slowness I did discover that I can do a whole bunch of them in parallel, getting the i/o rates 4000k/sec or so seemingly without any effect to anyone else. When it’s a 1TB LVM, I don't want to split them any further, but waiting an hour or two so isn't as bad as doing them one at a time. Thanks for the xargs tip! Good idea! -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Pavelka, Tomas Sent: Tuesday, March 04, 2014 12:01 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] dasdfmt slowness What we do to speed dasdfmt up is to split the large dasd into smaller minidisks and join them by LVM. Then the individual minidisks can be formatted in parallel. This is easy to script with xargs, which has the parameter --max-procs that lets you specify the maximum number of worker processes to spawn. Tomas -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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 lists...@vm.marist.edu 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/
DTCVSW2 BACKUP Not ready?
I just noticed that my DTCVSW2 controller is showing Error: BACKUP Not ready from the q vswitch command (probably not a good thing). Looks like the paths are online. Does anybody know how to get the backup controller DTCVSW2 back into a “ready” state (without taking an TCPIP burp or outage)? This is a z/VM 6.2 single VM system. q vswitch VSWITCH SYSTEM VSWZVMA1 Type: QDIOConnected: 18 Maxconn: INFINITE PERSISTENT RESTRICTEDNONROUTER Accounting: OFF USERBASED VLAN Unaware MAC address: 02-62-00-00-00-01MAC Protection: OFF IPTimeout: 5 QueueStorage: 8 Isolation Status: OFF Uplink Port: State: Ready PMTUD setting: EXTERNAL PMTUD value: 8992 RDEV: 0154.P01 VDEV: 0600 Controller: DTCVSW1 RDEV: 0160.P00 VDEV: 0600 Controller: DTCVSW2 Error: BACKUP Not ready q controller Controller DTCVSW1 Available: YES VDEV Range: 0600-F000 Level 620 Capability: IP ETHERNET VLAN_ARP GVRPLINKAGGISOLATION NO_ENSEMBLE NO_INMN BRIDGE_CAPABLE SYSTEM VSWZVMA1 Primary Controller: * RDEV: 0154 Controller DTCVSW2 Available: YES VDEV Range: 0600-F000 Level 620 Capability: IP ETHERNET VLAN_ARP GVRPLINKAGGISOLATION NO_ENSEMBLE NO_INMN BRIDGE_CAPABLE SYSTEM VSWZVMA1 Backup Controller: * RDEV: 0160 q path 154 Device 0154, Status ONLINE CHPIDs to Device 0154 (PIM) : 06 Physically Available (PAM) : + Online (LPM) : + Legend + Yes - No q path 160 Device 0160, Status ONLINE CHPIDs to Device 0160 (PIM) : 07 Physically Available (PAM) : + Online (LPM) : + Legend + Yes – No This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient of this e-mail (even if the e-mail address above is yours), (i) you may not use, copy or retransmit it, (ii) please delete this message and (iii) please notify the sender immediately. Any disclosure, copying, or distribution of this message or the taking of any action based on it, is strictly prohibited.
Re: DTCVSW2 BACKUP Not ready?
On 3/4/2014 at 03:16 PM, Tom Burkholder tom.burkhol...@qvc.com wrote: I just noticed that my DTCVSW2 controller is showing Error: BACKUP Not ready from the q vswitch command (probably not a good thing). Looks like the paths are online. Does anybody know how to get the backup controller DTCVSW2 back into a *ready* state (without taking an TCPIP burp or outage)? This is a z/VM 6.2 single VM system. This question would likely get far more of a response on the IBMVM mailing list, but I'll give it a try. The problem isn't with DTCVSW2, just RDEV 160. You should probably check to make sure it's got a cable plugged in, that the physical switch sees it, etc. Perhaps look at the HMC to see if anything there shows problems with the card, etc. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: DTCVSW2 BACKUP Not ready?
Mine shows this when there is actually a problem with the OSA .. such as not being cabled correctly or the switch port not being activated, etc.. are you sure the OSA at 160 port 0 is cabled up to an active switch port and ready to communicate? Scott Rohling On Tue, Mar 4, 2014 at 12:16 PM, Tom Burkholder tom.burkhol...@qvc.comwrote: I just noticed that my DTCVSW2 controller is showing Error: BACKUP Not ready from the q vswitch command (probably not a good thing). Looks like the paths are online. Does anybody know how to get the backup controller DTCVSW2 back into a ready state (without taking an TCPIP burp or outage)? This is a z/VM 6.2 single VM system. q vswitch VSWITCH SYSTEM VSWZVMA1 Type: QDIOConnected: 18 Maxconn: INFINITE PERSISTENT RESTRICTEDNONROUTER Accounting: OFF USERBASED VLAN Unaware MAC address: 02-62-00-00-00-01MAC Protection: OFF IPTimeout: 5 QueueStorage: 8 Isolation Status: OFF Uplink Port: State: Ready PMTUD setting: EXTERNAL PMTUD value: 8992 RDEV: 0154.P01 VDEV: 0600 Controller: DTCVSW1 RDEV: 0160.P00 VDEV: 0600 Controller: DTCVSW2 Error: BACKUP Not ready q controller Controller DTCVSW1 Available: YES VDEV Range: 0600-F000 Level 620 Capability: IP ETHERNET VLAN_ARP GVRPLINKAGGISOLATION NO_ENSEMBLE NO_INMN BRIDGE_CAPABLE SYSTEM VSWZVMA1 Primary Controller: * RDEV: 0154 Controller DTCVSW2 Available: YES VDEV Range: 0600-F000 Level 620 Capability: IP ETHERNET VLAN_ARP GVRPLINKAGGISOLATION NO_ENSEMBLE NO_INMN BRIDGE_CAPABLE SYSTEM VSWZVMA1 Backup Controller: * RDEV: 0160 q path 154 Device 0154, Status ONLINE CHPIDs to Device 0154 (PIM) : 06 Physically Available (PAM) : + Online (LPM) : + Legend + Yes - No q path 160 Device 0160, Status ONLINE CHPIDs to Device 0160 (PIM) : 07 Physically Available (PAM) : + Online (LPM) : + Legend + Yes - No This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient of this e-mail (even if the e-mail address above is yours), (i) you may not use, copy or retransmit it, (ii) please delete this message and (iii) please notify the sender immediately. Any disclosure, copying, or distribution of this message or the taking of any action based on it, is strictly prohibited. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: DTCVSW2 BACKUP Not ready?
Hello Scott and Mark... thanks for the reply. Tomorrow I'll have the Networking guy take a look at the actual switch ports, etc. and check some of his stuff. Tom B. - This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient of this e-mail (even if the e-mail address above is yours), (i) you may not use, copy or retransmit it, (ii) please delete this message and (iii) please notify the sender immediately. Any disclosure, copying, or distribution of this message or the taking of any action based on it, is strictly prohibited. - -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mark Post Sent: Tuesday, March 04, 2014 3:27 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: DTCVSW2 BACKUP Not ready? On 3/4/2014 at 03:16 PM, Tom Burkholder tom.burkhol...@qvc.com wrote: I just noticed that my DTCVSW2 controller is showing Error: BACKUP Not ready from the q vswitch command (probably not a good thing). Looks like the paths are online. Does anybody know how to get the backup controller DTCVSW2 back into a *ready* state (without taking an TCPIP burp or outage)? This is a z/VM 6.2 single VM system. This question would likely get far more of a response on the IBMVM mailing list, but I'll give it a try. The problem isn't with DTCVSW2, just RDEV 160. You should probably check to make sure it's got a cable plugged in, that the physical switch sees it, etc. Perhaps look at the HMC to see if anything there shows problems with the card, etc. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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 lists...@vm.marist.edu 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/
Writing a Mainframe Systems Programmer Resume
I would like to invite anyone attending next week's SHARE conference in Anaheim to come to my session on How to Write a Resume for a Mainframe Systems Programmer (session 15391, Tuesday, March 11, 12:15pm). It is the 8th time I have given this presentation at SHARE and it contains a lot of useful information and samples for the aspiring resume writer. Here is a link to my session: http://share.confex.com/share/122/webprogram/Session15391.html If you cannot attend, feel free to send me an email (or LinkedIn message) and I will send you a link to my PowerPoint slides (which will be available after March 11). If you're at SCIDS Sunday night, definitely track me (and Chris Evans) down and say hi. I am reachable by cell phone all week. Joe Gallaher j...@spci.net 323-822-1569 work 323-363-7259 cell http://www.SPCI.net http://www.linkedin.com/in/joegallaher You wouldn't hire a COBOL programmer to install your operating system. Why use an applications recruiter for your systems management needs? -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
