Re: dasdfmt - why are you so darn slow?
On 9 November 2012 00:41, Marcy Cortes marcy.d.cor...@wellsfargo.com wrote: I did NOREADCHECK and the time was identical. This is the ICKDSF format you were thinking of, right? CPVOL FMT MODE(ESA) UNIT(E886) VOLID(E886VM) NOVFY RANGE(0,10016) NOREADCHECK Yep. Apparently it's that cheap they did not bother to change the default option. I just purged the traces and forgot to check whether they were maybe reading with zero-length and suppress the transfer over the channel. For the time being, you could format it with ICKDSF and then DDR cylinder 1 from a Linux pack to fool dasdfmt... Really? That would work? Even on different sized minidisks? Ideally from the same size ;-) I though folks did mostly pseudo full-pack anyway. When you borrow the first 2 tracks from a larger disk, Linux will spit out a series of error messages when the head hits the wall, but then makes up his mind and fdasd -a does just fine. I have not tried using the tracks from a smaller disk. You don't really have to own those disks, but just keep a copy of the tracks in a CMS file PIPE trackread 300 0 0 2 | linuxdsk tracks a And then re-use that same set whenever you need it PIPE linuxdsk tracks | trackwrite 500 EMPTY 0 1 We did those things back then after flashing an empty disk on top of it (after the 'range' was removed from dasdfmt). Rob -- 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 - why are you so darn slow?
Ok, no shortage of spares here. So I tried it. Not good. dasdfmt of 1 cyl - non PPRC non XRC- 1:55 ICKDSF of 1 cyl - non PPRC non XRC - 1:13 LXFMT of 1 cyl - non PPRC non XRC - 2:10 dasdfmt of 1 cyl - PPRC, XRC'd - 5:00 ICKDSF of 1 cyl - PPRC, XRC'd - 1:29 LXFMT of 1 cyl - PPRC, XRC'd - 5:15 So, actually worse than dasdfmt. Marcy -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of David Boyes Sent: Thursday, November 08, 2012 6:44 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] dasdfmt - why are you so darn slow? For the time being, you could format it with ICKDSF and then DDR cylinder 1 from a Linux pack to fool dasdfmt... Has anyone tried LXFMT for comparison? I don't have a spare pack to try at the moment, but from reading the code, it seems to know a few more tricks about the 390 I/O system, and might be a more workable alternative while the Germany folks figure out how to make dasdfmt smarter. -- 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 - why are you so darn slow?
On 9 November 2012 23:52, Marcy Cortes marcy.d.cor...@wellsfargo.com wrote: Ok, no shortage of spares here. So I tried it. Not good. dasdfmt of 1 cyl - non PPRC non XRC- 1:55 ICKDSF of 1 cyl - non PPRC non XRC - 1:13 LXFMT of 1 cyl - non PPRC non XRC - 2:10 dasdfmt of 1 cyl - PPRC, XRC'd - 5:00 ICKDSF of 1 cyl - PPRC, XRC'd - 1:29 LXFMT of 1 cyl - PPRC, XRC'd - 5:15 So, actually worse than dasdfmt. That's 15 seconds more for 150,000 tracks. That 0.1 ms per I/O might be when they don't do short writes and transfer zeroes to the disk... Think at 4 Gb/s the 50KB per track would be around 0.1ms (but it's too late for math here now). Rob -- 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 - why are you so darn slow?
I have recently run a similar experiment measuring how fast do various disk operations run. Although I haven't attempted to compare dd with dasdfmt and the variation is high, here are the most commonly seen numbers: dasdfmt + pvcreate : 30-40 MB/s dd : 30-80 MB/s dasdfmt + pvcreate, parallel pool of 20 workers formatting all physical disks in a large LVM group: 150-300 MB/s After reading your results I have noticed that I have never seen dasdfmt run faster than 40 MB/s while I have regularly seen dd run at 80 MB/s. Tomas -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy Cortes Sent: Thursday, November 08, 2012 2:05 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: dasdfmt - why are you so darn slow? CA Hidro can copy one in 11 minutes. DFDSS can dump one to VTS in 6 minutes according to my z/OS guy dumping our stuff (I wouldn't think VTS would be quicker than DASD - maybe pretty similar) I haven't timed DDR but I don't think it is all that great either - certainly it is much worse the hidro. So yeah, I think both VM and Linux could be doing better here :) Marcy -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Robert J Brenneman Sent: Wednesday, November 07, 2012 4:15 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] dasdfmt - why are you so darn slow? Additionally - why does Linux not make better use of the I/O subsystem ? For example, a z/OS DSF copy job copying a dataset from one volume to another uses like 6% of a CPU at most, whereas Linux dd or cp uses 100% of a CPU, and doesn't go noticably faster than the DSF job. Could Linux make better use of CCWs to have the subsystem handle the copy rather than actually moving the data blocks through the main memory? -- Jay Brenneman -- 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/ -- 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 - why are you so darn slow?
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 -- 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 - why are you so darn slow?
On 8 November 2012 00:58, Marcy Cortes marcy.d.cor...@wellsfargo.com wrote: The list is a little quiet so I thought I would ask this. 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? The full answer involves data and experiments and could at least excite the presenter for an hour ;-) (you can blame Marcy if you get trapped in there) On a real round brown disk, doing a format write is a delicate process that requires dedication and a steady hand. It's done one track at a time. This takes a full round trip per track, so roughly 1 million of those in your case. Given that, 20 would be explained. If there's more FICON things in between, there may be more hops to take and your I/O response might be worse. The amount of data does not look like it would saturate your NVS, but who knows what else is going on. If you upload an hour of data while this was running, I'd be most happy to investigate what is going on and whether there is room for improvement. Depending on where the bottleneck is, you could imagine to do PAV and a multi-threaded dasdfmt. We used to be able to tell dasdfmt to do just a range of cylinders (so you could run more in parallel) but that option was taken out because people forgot to format the entire disk When simply writing data (rather than format write) you can chain many tracks in a single I/O and need far less round trips and are down to the transfer rates. With high channel bandwidth that may indeed be faster. Most fun is to flashcopy a previously formatted pack. PS No, dasdfmt does not do a verify. There is a bit of reading afterwards, but that's it. ICKDSF however does do a verify. Rob -- 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 - why are you so darn slow?
Assuming that the count/key information is really just meta data and doesn't have the same physical presence as it did on real 3340/50/80/90 devices, and given that this type of operation is common; I was wondering whether creating a new CCW to do the format and let the controller/device take care of everything wouldn't be worth doing. The define extent already bounds the range of the format, a parameter list consisting of the start of the count field, record count per track, block size, and fill character could be provided and the controller could do its thing. If it were a large area then several such format operations could be done if you didn't want to seize the device (or use PAV). -- 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 - why are you so darn slow?
On Thursday, 11/08/2012 at 06:47 EST, Rob van der Heij rvdh...@gmail.com wrote: On a real round brown disk, doing a format write is a delicate process that requires dedication and a steady hand. It's done one track at a time. This takes a full round trip per track, so roughly 1 million of those in your case. Given that, 20 would be explained. If there's more FICON things in between, there may be more hops to take and your I/O response might be worse. The amount of data does not look like it would saturate your NVS, but who knows what else is going on. If you upload an hour of data while this was running, I'd be most happy to investigate what is going on and whether there is room for improvement. DS8000s return Device End as soon as the data is in NVS (non-volatile storage). Data is written to disk asynchronously, so the physical organization of a track is transparent to the I/O operation. Managing the cache to avoid I/O delays due to NVS destaging operations is one of the things a smart controller has to handle.) I will make the rash assumption that all modern storage controllers with NVS cache operate the same way. Alan Altmark Senior Managing z/VM and Linux Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott -- 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 - why are you so darn slow?
PS No, dasdfmt does not do a verify. There is a bit of reading afterwards, but that's it. ICKDSF however does do a verify. Interesting, isn't end-to-end data checking provided by FICON I/O about there not being a need for data verification? At the time you wrote the data and got a successful completion status you know it ended up fine on the device? i.e. verification only satisfying paranoia? Mit freundlichem Gruß / Best regards Ingo Adlung Ingo AdlungIBM Deutschland Research IBM Distinguished Engineer Development GmbH Chief Architect, System z Vorsitzender des Aufsichtsrats: Virtualization Linux Martina Koederitz mail: adl...@de.ibm.comGeschäftsführung: Dirk Wittkopp phone: +49-7031-16-4263; fax: Sitz der Gesellschaft: Böblingen +49-7031-16-3456 Registergericht: Amtsgericht Stuttgart, HRB 243294 Linux on 390 Port LINUX-390@vm.marist.edu wrote on 08.11.2012 12:43:10: From: Rob van der Heij rvdh...@gmail.com To: LINUX-390@vm.marist.edu, Date: 08.11.2012 12:47 Subject: Re: [LINUX-390] dasdfmt - why are you so darn slow? Sent by: Linux on 390 Port LINUX-390@vm.marist.edu On 8 November 2012 00:58, Marcy Cortes marcy.d.cor...@wellsfargo.com wrote: The list is a little quiet so I thought I would ask this. 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? The full answer involves data and experiments and could at least excite the presenter for an hour ;-) (you can blame Marcy if you get trapped in there) On a real round brown disk, doing a format write is a delicate process that requires dedication and a steady hand. It's done one track at a time. This takes a full round trip per track, so roughly 1 million of those in your case. Given that, 20 would be explained. If there's more FICON things in between, there may be more hops to take and your I/O response might be worse. The amount of data does not look like it would saturate your NVS, but who knows what else is going on. If you upload an hour of data while this was running, I'd be most happy to investigate what is going on and whether there is room for improvement. Depending on where the bottleneck is, you could imagine to do PAV and a multi-threaded dasdfmt. We used to be able to tell dasdfmt to do just a range of cylinders (so you could run more in parallel) but that option was taken out because people forgot to format the entire disk When simply writing data (rather than format write) you can chain many tracks in a single I/O and need far less round trips and are down to the transfer rates. With high channel bandwidth that may indeed be faster. Most fun is to flashcopy a previously formatted pack. PS No, dasdfmt does not do a verify. There is a bit of reading afterwards, but that's it. ICKDSF however does do a verify. Rob -- 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 - why are you so darn slow?
On 8 November 2012 16:31, Alan Altmark alan_altm...@us.ibm.com wrote: On Thursday, 11/08/2012 at 06:47 EST, Rob van der Heij rvdh...@gmail.com wrote: On a real round brown disk, doing a format write is a delicate process that requires dedication and a steady hand. It's done one track at a time. This takes a full round trip per track, so roughly 1 million of those in your case. Given that, 20 would be explained. If there's more FICON things in between, there may be more hops to take and your I/O response might be worse. The amount of data does not look like it would saturate your NVS, but who knows what else is going on. If you upload an hour of data while this was running, I'd be most happy to investigate what is going on and whether there is room for improvement. DS8000s return Device End as soon as the data is in NVS (non-volatile storage). Data is written to disk asynchronously, so the physical organization of a track is transparent to the I/O operation. Managing the cache to avoid I/O delays due to NVS destaging operations is one of the things a smart controller has to handle.) I will make the rash assumption that all modern storage controllers with NVS cache operate the same way. You're correct. However, formatting is a bit unfair competition because you can write short records and have the control unit provide the omitted zeroes. So the channel speed is not slowing you down. Depending on how the smarts are done in the subsystem, you might fill up NVS quicker than the collective back-end can absorb. At that point your I/O will be slowed down to the rate of the back-end (with all the write penalties). Among the smart things is also how to avoid a single I/O stream monopolize the cache before hitting the wall anyway. And knowing the OP, it's very well possible she was doing this on a device that is under synchronous PPRC and the Device End is waiting for the other side. Rob -- 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 - why are you so darn slow?
On 8 November 2012 16:31, Ingo Adlung adl...@de.ibm.com wrote: PS No, dasdfmt does not do a verify. There is a bit of reading afterwards, but that's it. ICKDSF however does do a verify. Interesting, isn't end-to-end data checking provided by FICON I/O about there not being a need for data verification? At the time you wrote the data and got a successful completion status you know it ended up fine on the device? i.e. verification only satisfying paranoia? ICKDSF was written in the days where the operator had to turn the platters by hand (like DJ's do these days). ;-) I was thinking that the verify would be cheap with the track still in control unit cache. But I now notice that ICKDSF does know how to do multiple tracks in one I/O, so I need to dig deeper to understand why it's not significantly faster. Rob -- 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 - why are you so darn slow?
Yes, Rob is right (as usual). Definitely PPRC is in play with the numbers I reported. Probably XRC write pacing is involved too. I tried it on a non-PPRC'd, non-XRC'd device. I only had 10,000 cyl available there. That took 3:30. If I assume linear and multiple by 6.55 that would be 23 minutes. Writing all zeros took 2:03 - so that would be about 13.5 minutes. FWIW the PPRC is 11 miles and normally adds about 1 ms to i/o time. So I do have a penalty there, but dasdfmt could be doing much better.We'll wait to see what Peter O comes up with :) Marcy -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Rob van der Heij Sent: Thursday, November 08, 2012 7:59 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] dasdfmt - why are you so darn slow? On 8 November 2012 16:31, Alan Altmark alan_altm...@us.ibm.com wrote: On Thursday, 11/08/2012 at 06:47 EST, Rob van der Heij rvdh...@gmail.com wrote: On a real round brown disk, doing a format write is a delicate process that requires dedication and a steady hand. It's done one track at a time. This takes a full round trip per track, so roughly 1 million of those in your case. Given that, 20 would be explained. If there's more FICON things in between, there may be more hops to take and your I/O response might be worse. The amount of data does not look like it would saturate your NVS, but who knows what else is going on. If you upload an hour of data while this was running, I'd be most happy to investigate what is going on and whether there is room for improvement. DS8000s return Device End as soon as the data is in NVS (non-volatile storage). Data is written to disk asynchronously, so the physical organization of a track is transparent to the I/O operation. Managing the cache to avoid I/O delays due to NVS destaging operations is one of the things a smart controller has to handle.) I will make the rash assumption that all modern storage controllers with NVS cache operate the same way. You're correct. However, formatting is a bit unfair competition because you can write short records and have the control unit provide the omitted zeroes. So the channel speed is not slowing you down. Depending on how the smarts are done in the subsystem, you might fill up NVS quicker than the collective back-end can absorb. At that point your I/O will be slowed down to the rate of the back-end (with all the write penalties). Among the smart things is also how to avoid a single I/O stream monopolize the cache before hitting the wall anyway. And knowing the OP, it's very well possible she was doing this on a device that is under synchronous PPRC and the Device End is waiting for the other side. Rob -- 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 - why are you so darn slow?
On 8 November 2012 18:03, Marcy Cortes marcy.d.cor...@wellsfargo.com wrote: Yes, Rob is right (as usual). Definitely PPRC is in play with the numbers I reported. Probably XRC write pacing is involved too. I tried it on a non-PPRC'd, non-XRC'd device. I only had 10,000 cyl available there. That took 3:30. If I assume linear and multiple by 6.55 that would be 23 minutes. Writing all zeros took 2:03 - so that would be about 13.5 minutes. FWIW the PPRC is 11 miles and normally adds about 1 ms to i/o time. My guess for 20 min was assuming 1 ms I/O response. Adding 1 ms for PRPC gives you 40 min. So I do have a penalty there, but dasdfmt could be doing much better. We'll wait to see what Peter O comes up with :) While you're at it, give ICKDSF a try on the non-PPRC volume. From looking at the trace, I would expect it take 1/10th of the SSCH's and thus have less of the round trip overhead. That's something dasdfmt could use as well. Rob -- 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 - why are you so darn slow?
OK I compared ICKDSF to dasdfmt for Rob. And the other tests I happened to have run from the CPU at the site that didn't have the primary dasd. I was essentially adding another 11miles. Oops - not what I was intending to look at! dasdfmt of 1 cyl - non PPRC non XRC- 1:55 ICKDSF of 1 cyl - non PPRC non XRC - 1:13 dasdfmt of 1 cyl - PPRC, XRC'd - 5:00 ICKDSF of 1 cyl - PPRC, XRC'd - 1:29 dasdfmt takes 57% more time thank ICKDSF on non-replicated disk and 237% more time on replicated disk if I did my math right. It looks like dasdfmt suffers way more at the hands of replication. Definitely room for improvement in it. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Rob van der Heij Sent: Thursday, November 08, 2012 9:22 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] dasdfmt - why are you so darn slow? On 8 November 2012 18:03, Marcy Cortes marcy.d.cor...@wellsfargo.com wrote: Yes, Rob is right (as usual). Definitely PPRC is in play with the numbers I reported. Probably XRC write pacing is involved too. I tried it on a non-PPRC'd, non-XRC'd device. I only had 10,000 cyl available there. That took 3:30. If I assume linear and multiple by 6.55 that would be 23 minutes. Writing all zeros took 2:03 - so that would be about 13.5 minutes. FWIW the PPRC is 11 miles and normally adds about 1 ms to i/o time. My guess for 20 min was assuming 1 ms I/O response. Adding 1 ms for PRPC gives you 40 min. So I do have a penalty there, but dasdfmt could be doing much better. We'll wait to see what Peter O comes up with :) While you're at it, give ICKDSF a try on the non-PPRC volume. From looking at the trace, I would expect it take 1/10th of the SSCH's and thus have less of the round trip overhead. That's something dasdfmt could use as well. Rob -- 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 - why are you so darn slow?
On 8 November 2012 20:54, Marcy Cortes marcy.d.cor...@wellsfargo.com wrote: OK I compared ICKDSF to dasdfmt for Rob. And the other tests I happened to have run from the CPU at the site that didn't have the primary dasd. I was essentially adding another 11miles. Oops - not what I was intending to look at! dasdfmt of 1 cyl - non PPRC non XRC- 1:55 ICKDSF of 1 cyl - non PPRC non XRC - 1:13 dasdfmt of 1 cyl - PPRC, XRC'd - 5:00 ICKDSF of 1 cyl - PPRC, XRC'd - 1:29 dasdfmt takes 57% more time thank ICKDSF on non-replicated disk and 237% more time on replicated disk if I did my math right. I would have expected ICKDSF to have more advantage, but maybe the cost of reading back the cylinder is pretty heavy. I wish I had suggested the NOREADCHK option. It looks like dasdfmt suffers way more at the hands of replication. Definitely room for improvement in it. It may be that the microcode in the disk subsystem recognizes the channel program and does smart things instead of replicating 64K per track to the other side. But the differences between the channel programs are just too big to just guess at where the trick is... For the time being, you could format it with ICKDSF and then DDR cylinder 1 from a Linux pack to fool dasdfmt... Rob -- 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 - why are you so darn slow?
I did NOREADCHECK and the time was identical. This is the ICKDSF format you were thinking of, right? CPVOL FMT MODE(ESA) UNIT(E886) VOLID(E886VM) NOVFY RANGE(0,10016) NOREADCHECK For the time being, you could format it with ICKDSF and then DDR cylinder 1 from a Linux pack to fool dasdfmt... Really? That would work? Even on different sized minidisks? Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Rob van der Heij Sent: Thursday, November 08, 2012 2:10 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] dasdfmt - why are you so darn slow? On 8 November 2012 20:54, Marcy Cortes marcy.d.cor...@wellsfargo.com wrote: OK I compared ICKDSF to dasdfmt for Rob. And the other tests I happened to have run from the CPU at the site that didn't have the primary dasd. I was essentially adding another 11miles. Oops - not what I was intending to look at! dasdfmt of 1 cyl - non PPRC non XRC- 1:55 ICKDSF of 1 cyl - non PPRC non XRC - 1:13 dasdfmt of 1 cyl - PPRC, XRC'd - 5:00 ICKDSF of 1 cyl - PPRC, XRC'd - 1:29 dasdfmt takes 57% more time thank ICKDSF on non-replicated disk and 237% more time on replicated disk if I did my math right. I would have expected ICKDSF to have more advantage, but maybe the cost of reading back the cylinder is pretty heavy. I wish I had suggested the NOREADCHK option. It looks like dasdfmt suffers way more at the hands of replication. Definitely room for improvement in it. It may be that the microcode in the disk subsystem recognizes the channel program and does smart things instead of replicating 64K per track to the other side. But the differences between the channel programs are just too big to just guess at where the trick is... For the time being, you could format it with ICKDSF and then DDR cylinder 1 from a Linux pack to fool dasdfmt... Rob -- 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 - why are you so darn slow?
For the time being, you could format it with ICKDSF and then DDR cylinder 1 from a Linux pack to fool dasdfmt... Has anyone tried LXFMT for comparison? I don't have a spare pack to try at the moment, but from reading the code, it seems to know a few more tricks about the 390 I/O system, and might be a more workable alternative while the Germany folks figure out how to make dasdfmt smarter. -- 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/
dasdfmt - why are you so darn slow?
The list is a little quiet so I thought I would ask this. 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? 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/
Re: dasdfmt - why are you so darn slow?
Did you get a coffee? On 11/07/2012 05:58 PM, Marcy Cortes wrote: The list is a little quiet so I thought I would ask this. 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? 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/ -- Richard Smrcina Sr. Systems Engineer Velocity Software Inc. Main: (650) 964-8867 Main: (877) 964-8867 r...@velocitysoftware.com mailto://r...@velocitysoftware.com Signature http://www.velocitysoftware.com/ *Follow us:* facebook http://www.facebook.com/pages/Velocity-Software/356098274460840 LinkedIn http://www.linkedin.com/company/1798379?trk=tyah twitter https://twitter.com/VelocitySoftw Xing https://www.xing.com/companies/velocitysoftwaregmbhhttps://www.xing.com/companies/velocitysoftwaregmbh -- 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 - why are you so darn slow?
Forgot to mention that! It's getting pricey walking over to Peet's all the time! Marcy -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Rich Smrcina Sent: Wednesday, November 07, 2012 4:08 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] dasdfmt - why are you so darn slow? Did you get a coffee? On 11/07/2012 05:58 PM, Marcy Cortes wrote: The list is a little quiet so I thought I would ask this. 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? 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/ -- Richard Smrcina Sr. Systems Engineer Velocity Software Inc. Main: (650) 964-8867 Main: (877) 964-8867 r...@velocitysoftware.com mailto://r...@velocitysoftware.com Signature http://www.velocitysoftware.com/ *Follow us:* facebook http://www.facebook.com/pages/Velocity-Software/356098274460840 LinkedIn http://www.linkedin.com/company/1798379?trk=tyah twitter https://twitter.com/VelocitySoftw Xing https://www.xing.com/companies/velocitysoftwaregmbhhttps://www.xing.com/companies/velocitysoftwaregmbh -- 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 - why are you so darn slow?
Additionally - why does Linux not make better use of the I/O subsystem ? For example, a z/OS DSF copy job copying a dataset from one volume to another uses like 6% of a CPU at most, whereas Linux dd or cp uses 100% of a CPU, and doesn't go noticably faster than the DSF job. Could Linux make better use of CCWs to have the subsystem handle the copy rather than actually moving the data blocks through the main memory? -- Jay Brenneman -- 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 - why are you so darn slow?
Could it be doing a verify of what was just written? Sent from my iPhone On Nov 7, 2012, at 19:08, Rich Smrcina r...@velocitysoftware.com wrote: Did you get a coffee? On 11/07/2012 05:58 PM, Marcy Cortes wrote: The list is a little quiet so I thought I would ask this. 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? 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/ -- Richard Smrcina Sr. Systems Engineer Velocity Software Inc. Main: (650) 964-8867 Main: (877) 964-8867 r...@velocitysoftware.com mailto://r...@velocitysoftware.com Signature http://www.velocitysoftware.com/ *Follow us:* facebook http://www.facebook.com/pages/Velocity-Software/356098274460840 LinkedIn http://www.linkedin.com/company/1798379?trk=tyah twitter https://twitter.com/VelocitySoftw Xing https://www.xing.com/companies/velocitysoftwaregmbhhttps://www.xing.com/companies/velocitysoftwaregmbh -- 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 - why are you so darn slow?
CA Hidro can copy one in 11 minutes. DFDSS can dump one to VTS in 6 minutes according to my z/OS guy dumping our stuff (I wouldn't think VTS would be quicker than DASD - maybe pretty similar) I haven't timed DDR but I don't think it is all that great either - certainly it is much worse the hidro. So yeah, I think both VM and Linux could be doing better here :) Marcy -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Robert J Brenneman Sent: Wednesday, November 07, 2012 4:15 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] dasdfmt - why are you so darn slow? Additionally - why does Linux not make better use of the I/O subsystem ? For example, a z/OS DSF copy job copying a dataset from one volume to another uses like 6% of a CPU at most, whereas Linux dd or cp uses 100% of a CPU, and doesn't go noticably faster than the DSF job. Could Linux make better use of CCWs to have the subsystem handle the copy rather than actually moving the data blocks through the main memory? -- Jay Brenneman -- 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/
