> 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 Adlung IBM Deutschland Research &
IBM Distinguished Engineer Development GmbH
Chief Architect, System z Vorsitzender des Aufsichtsrats:
Virtualization & Linux Martina Koederitz
mail: [email protected] Geschä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 <[email protected]> wrote on 08.11.2012 12:43:10:
> From: Rob van der Heij <[email protected]>
> To: [email protected],
> Date: 08.11.2012 12:47
> Subject: Re: [LINUX-390] dasdfmt - why are you so darn slow?
> Sent by: Linux on 390 Port <[email protected]>
>
> On 8 November 2012 00:58, Marcy Cortes <[email protected]>
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 [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/
