I actually setup DIRMAINT (using a user exit) at one customer to format deleted minidisks with LXFMT rather then FORMAT .. worked great - but really only useful if you hand out the same size minidisks to Linux guests (this customer strictly used 1-END minidisks for Linux guests, so it saved quite a bit of time for them). We also preformatted disks before adding them to the pool with LXFMT .. so the end result was that Linux never had to issue dasdfmt or fdasd itself. All disks in the storage pool for Linux guests were already preformatted...
Scott Rohling On Wed, Mar 13, 2013 at 3:02 PM, O'Brien, Dennis L < dennis.l.o'[email protected]> wrote: > Tomas, > There's another possibility: format the DASD from CMS using the LXFMT > program. That eliminates the need to format again from Linux. LXFMT is > available on Sine Nomine's web site. > > > Dennis > O'Brien > > Wanted, Dead and Alive: Schrödinger's Cat > > -----Original Message----- > From: Linux on 390 Port [mailto:[email protected]] On Behalf Of > Pavelka, Tomas > Sent: Wednesday, March 13, 2013 01:59 > To: [email protected] > Subject: Re: DASD format from Linux only > > Thanks for the replies, here are my thoughts on the problem: > > I agree that before a minidisk is given to a guest (before the guest is > started for the first time) the minidisk needs to be formatted and any data > that was previously on the disk erased. The question is, when to do it and > from which OS. > I have the ability to create both the new guest and the minidisk from > Linux (via SMAPI) but not the ability to safely format the disk from Linux, > because I cannot safely bring the disk online for format. By unsafe I mean > that bringing the disk online can create contention on the real device that > can last several minutes. > > There are several possibilities I can think of: > 1) Format every newly created disk in CMS before formatting in Linux. > Directory maintenance products can do this. This means every disk would be > formatted twice and every new disk creation would take twice as long > (unless you stay with CMS format and not use CDL at all). > 2) Do a security erase on every deleted disk. Again directory managers can > do this, but the setting is optional. If you want to do this, you have to > follow this rigorously on the entire DASD pool on which minidisks are > created. One deletion without security erase can potentially cause trouble. > 3) Write nonsense data to the first tracks of the disk so that Linux would > not recognize it as a known format and would not go into loops when the > data on the disk is not right. Similar to 1) but faster. > > After this, it is safe to format a disk with CDL from Linux. > > As Mark has suggested, I need the ability to format the disk from Linux > without needing to put it online first with Linux examining the contents. > Without this, the CDL format is incomplete as it can only be safely applied > to an already formatted disk. > > As for the security question about Linux running on LPAR with disk shared > by z/OS: what makes Linux different from other platforms? If Linux is not > used to format disks, there must be another OS that has the ability to wipe > out any of the shared disks and the person doing the format must know which > disk they are formatting. Also, we are talking about security in the sense > of preventing accidental deletion. A malicious user having access to Linux > sharing disks with zOS can do harm to the shared disks by using > raw_track_access unless the shared disks are protected against access from > Linux. (As long as the attacker knows CKD architecture. As I have recently > learned, you cannot just redirect /dev/zero to the disk in raw track format > ;-)) > > Tomas > > ---------------------------------------------------------------------- > 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/ > > ---------------------------------------------------------------------- > This message, and any attachments, is for the intended recipient(s) only, > may contain information that is privileged, confidential and/or proprietary > and subject to important terms and conditions available at > http://www.bankofamerica.com/emaildisclaimer. If you are not the > intended recipient, please delete this message. > > ---------------------------------------------------------------------- > 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/
