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:[email protected]] On Behalf Of Rob van der Heij Sent: Thursday, November 08, 2012 7:59 AM To: [email protected] Subject: Re: [LINUX-390] dasdfmt - why are you so darn slow? On 8 November 2012 16:31, Alan Altmark <[email protected]> wrote: > On Thursday, 11/08/2012 at 06:47 EST, Rob van der Heij > <[email protected]> > 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 [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/
