Re: Minidisk support (was: Installation Question)
On 2009-12-15, Stephen Powell wrote: OK, so if all three drivers support minidisks, then what is Debian bug report 447755 all about? The issue here is the *format* of the minidisk. A DASD device, be it a dedicated device or a minidisk, can have one of four formats under Linux for s390: cdl, ldl, CMS non-reserved, and CMS reserved. The FBA driver supports two of the four formats: CMS non-reserved and CMS reserved. The DIAG driver supports three of the four formats: ldl, CMS non-reserved, and CMS reserved. The ECKD driver supports all four formats. I need to make one further clarification. The DIAG driver (dasd_diag_mod) really doesn't *take the place* of the basic driver for the underlying dasd type (dasd_fba_mod or dasd_eckd_mod, depending on whether the device is an FBA device or a CKD device). Rather it works *with* the basic driver for the underlying dasd type. The basic driver (dasd_fba_mod or dasd_eckd_mod) makes some initial tests of the device to see if it qualifies for use by the DIAG driver. For example: Are we running in a virtual machine under z/VM? Is it a supported device type? Is it a supported format? Does it have a valid block size? etc. Once the basic driver is satisfied that the device qualifies, it hands it off to the DIAG driver. That means two things: (1) the initial RAM file system must contain both drivers, and both drivers must be loaded from the initial RAM file system, and (2) the set of formats supported by the DIAG driver *for a particular device* is the intersection of sets of the set of formats supported by the DIAG driver and the set of formats supported by the basic driver for that type of device. For example, when using the DIAG driver with an FBA device, one can only use the CMS non-reserved or the CMS reserved format. The ldl format cannot be used by the DIAG driver for this type of device, even though the DIAG driver supports the ldl format, because the underlying basic driver, the FBA driver in this case, does not support the ldl format. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Minidisk support (was: Installation Question)
At the risk of flogging a dead horse, there's one more minor correction I need to make. On 2009-12-15, Stephen Powell wrote: cdl format: Low-level formatting: dasdfmt -d cdl (this is the default format for dasdfmt) Partitioning: fdasd (up to three partitions can be created) High-level formatting: mke2fs or mkswap ldl format: Low-level formatting: dasdfmt -d ldl Partitioning: none (a single partition is implied) High-level formatting: mke2fs or mkswap CMS non-reserved: Low-level formatting: CMS FORMAT command Partitioning: none (a single partition is implied) High-level formatting: mke2fs or mkswap CMS reserved: Low-level formatting: CMS FORMAT command Partitioning: CMS RESERVE command (a single partition is created) High-level formatting: mke2fs or mkswap In the above section I imply that high-level formatting must be done by either mke2fs or mkswap. This is not strictly true. Other file systems besides ext2 or ext3 may be used. It would be more accurate to say mkfs or mkswap for the high-level formatting part of each of the four disk formats. This allows any desired (and supported) filesystem to be used. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Installation Question
Martin, Larry D wrote: The S390 directory appears to me to be empty this week. Yes, unfortunately there was a build error this week (which sometimes happens for daily and weekly builds). The images should be back next Monday. There was stuff there last week (can I point to that?). Afraid not. Full CD/DVD images just take too much space to keep multiple versions around. Cheers, FJP -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RE: Installation Question
Thanks..Larry -Original Message- From: Frans Pop [mailto:elen...@planet.nl] Sent: Wednesday, December 16, 2009 11:59 AM To: debian-s390@lists.debian.org Subject: Re: Installation Question Martin, Larry D wrote: The S390 directory appears to me to be empty this week. Yes, unfortunately there was a build error this week (which sometimes happens for daily and weekly builds). The images should be back next Monday. There was stuff there last week (can I point to that?). Afraid not. Full CD/DVD images just take too much space to keep multiple versions around. Cheers, FJP -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org This E-mail and any of its attachments may contain Prince George’s County Government or Prince George's County 7th Judicial Circuit Court proprietary information, which is privileged and confidential. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Re: Minidisk support
On 2009-12-15, Stephen Powell wrote: My own attempts to backport the official fix to 2.6.26 have so far been unsuccessful due to my minuscule C skills. I'm getting compile errors that I have so far not been able to resolve. Fortunately, I have a simpler patch that works well enough for me. Well, I finally succeeded in backporting the official DIAG patch from 2.6.33 to 2.6.26. I was having trouble earlier with substitution parameters in messages (like %s, %d, etc.). I finally figured out how that stuff works well enough to backport the fix to 2.6.26 (i.e. Lenny). Of course, it's unofficial. It doesn't come directly from the kernel people. But I have tested it, and it applies cleanly, compiles cleanly, and appears to execute correctly. I tested it as well as I could on my system, and it works great. Here is a link to the backported patch, if anyone wants it: http://www.wowway.com/~zlinuxman/dasd_diag.patch For reference again, here is the upstream commit link, courtesy of Peter Oberparleiter: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=22825ab7693fd29769518a0d25ba43c01a50092a P.S. I wonder if we could make a case for including this fix in Lenny on security grounds? The rationale would be that without this patch, sharing minidisks with the DIAG driver requires multiple simultaneous read/write links (access mode MW), which carries with it the risk that two different servers might accidentally mount the file system read/write at the same time, which will corrupt the minidisk. With the patch, the minidisks can be linked read-only, which eliminates the risk. Of course, I am not an upstream kernel person, nor a Debian developer, nor a Debian security person; so someone would have to step up and sponsor this. Just a thought. Suse apparently thought the fix important enough to backport it to SLES10 (2.6.16) and SLES11 (2.6.27). So if Debian decided to do this they would be in good company. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
