Re: Interesting tweet - kvm
Marcy Cortes píše v Čt 08. 11. 2012 v 16:23 -0600: > Google found this > http://kvmforumovirtworkshop2012.sched.org/event/cf566f514621e3e7e04f1974eb08cb9f and also found this thread with a patch set http://lists.gnu.org/archive/html/qemu-devel/2012-09/msg00340.html Dan -- Dan Horák, RHCE Senior Software Engineer, BaseOS Red Hat Czech s.r.o., Purkyňova 99, 612 45 Brno -- 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/
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 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: Interesting tweet - kvm
Barcelona On Thu, Nov 8, 2012 at 4:49 PM, Neale Ferguson wrote: > At #KVM Forum? Don't miss: "KVM on IBM System z: Channel I/O And How To > Virtualize It" by #IBM - Nov 9 at 10:30am. Anyone have details? > > -- > 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/ -- -- R; <>< '::1, sweet ::1' -- 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: Interesting tweet - kvm
Google found this http://kvmforumovirtworkshop2012.sched.org/event/cf566f514621e3e7e04f1974eb08cb9f 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 Neale Ferguson Sent: Thursday, November 08, 2012 1:50 PM To: LINUX-390@VM.MARIST.EDU Subject: [LINUX-390] Interesting tweet - kvm At #KVM Forum? Don't miss: "KVM on IBM System z: Channel I/O And How To Virtualize It" by #IBM - Nov 9 at 10:30am. Anyone have details? -- 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 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/
Interesting tweet - kvm
At #KVM Forum? Don't miss: "KVM on IBM System z: Channel I/O And How To Virtualize It" by #IBM - Nov 9 at 10:30am. Anyone have details? -- 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 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: CKBKVM62.tgz
Hello list, Alan Levy wrote: > The link in the book is not working. Sure enough, the link (z/VM file name) for the latest Virtualization Cookbook is CKB-VM62, which I had just about everywhere in the book except for one important place in section 4.2, where I had CKBKVM62. That is now fixed. As I was doing a quick comparison of the old and new PDFs, I noticed the new book was 6 pages longer. I forgot that I had added two sections: 16.4.4 "Setting up subversion" and 16.4.5 "Create an RPM". I had needed to set up a development Linux and documented the steps for reference. They're not 100% polished (seems I somehow started on RHEL but finished on SLES), but hopefully may be useful. Enjoy! "Mike MacIsaac" -- 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: RHEL 6.2 dying on shutdown
Hello List, I had written back on Oct 12th: > This is odd - I'm having a RHEL 6.2 system die on shutdown while trying to > shut down the loopback interface: > > Shutting down system logger: Ý OK ¨ > Shutting down interface eth0: Ý OK ¨ > Shutting down loopback interface: Ý OK ¨ > INFO: task vgs:2171 blocked for more than 120 seconds. > ... I'm following up as there seems to be closure. I believe there were two things going on: 1) I neglected to use the znetconf -A command when setting up a second network interface 2) RHEL 6.2 froze at shutdown, as described. So if I address (1) by adding the znetconf call, then (2) does not arise. Still Linux should be more bulletproof than than, so I opened a Red Hat Bugzilla entry (872702). Further, it seems to have later caused the issues I encountered later with LVM and SCSI/FCP disks. Now that I addressed (1), I am not seeing that issue either. Yes I agree it seems strange that setting up a network interface can affect LVMs, but that sure seems to be the case. Thanks to Steffen Maier, Rick Troth and Filipe Miranda for their help on this. "Mike MacIsaac" -- 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 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?
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 wrote: > On Thursday, 11/08/2012 at 06:47 EST, Rob van der Heij > > 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 16:31, Ingo Adlung 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?
On 8 November 2012 16:31, Alan Altmark wrote: > On Thursday, 11/08/2012 at 06:47 EST, Rob van der Heij > 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?
> 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 wrote on 08.11.2012 12:43:10: > From: Rob van der Heij > 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 > > On 8 November 2012 00:58, 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? > > > > 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 Thursday, 11/08/2012 at 06:47 EST, Rob van der Heij 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?
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: Any Official HMC Screenshots?
How about SC28-6895-01, Hardware Management Console Operations Guide, Version 2.11.0? Klaus Bergmann -- 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 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?
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: Any Official HMC Screenshots?
Hi Mark, On 11/07/2012 11:52 PM, Mark Post wrote: Cross-posted to Linux-390, IBMVM and IBM-MAIN. I'm developing some documentation which deals with Linux installation into an LPAR. I would like to include images/screenshots of the various HMC screens involved so that the end-user can better relate the text to what they're going to see on a real HMC. Does any of the official IBM manuals have any images like that included? I know some of the Redbooks do, but I would prefer something other than those if possible. I don't know about copying content from our books but would the following be what you're looking for?: http://www.ibm.com/developerworks/linux/linux390/documentation_dev.html Book "Device Drivers, Features, and Commands" * for operating system messages console: Chapter "Console device drivers" * for LPAR image load of the installer: Chapter "Booting Linux" Section "Booting Linux in LPAR mode" Subsection "Loading Linux from removable media or from an FTP server" The distro specific stuff should be in distro documentation, i.e. what the content of the operating system messages console looks like per distro installer. Steffen Linux on System z Development IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 -- 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/
