Re: Minidisk support
On 14.12.2009 18:37, Frans Pop wrote: As mentioned before, I'm not sure that this qualifies for Lenny. Any backport is a risk and the number of users that will benefit is uncertain, but likely to be low. It might be different if other users spoke up... Is it worth the effort? Not sure if this helps, but the patch was recently added to Novell's SLES11 kernel 2.6.27.39-0.3.1 and SLES10 kernel 2.6.16.60-0.58.1 and is currently in review for RedHat's RHEL5 kernel. Regards, Peter Oberparleiter -- 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)
That's really the wrong way to look at it. Just look at the headers from the mail: they clearly show that the mail was sent to you by the mailing list software. It was delivered to you because *you* subscribed to the list, not because *I* sent it to you. Other mail clients (such as my own kmail) by default automatically reply to the mailing list only. Your client probably has a reply-to-list option. The e-mail client I normally use is the the browser-based basic webmail client of my ISP, which happens to be WOW! It is a cable TV company which also offers high speed internet connectivity via a cable modem. They give free e-mail accounts to their cable-modem customers. And they have a basic and an advanced browser-based webmail client. I don't use the e-mail client installed on my workstation. I prefer web-based e-mail for a number of reasons, but I won't go into it here because it's off-topic. The point is that, as seen by my e-mail client, the incoming e-mail says To: debian-s390@lists.debian.org From: (poster's e-mail address) When I click on reply, the To field is pre-filled-in with the poster's e-mail address. I have to remember to do a copy, while still on the page for the incoming e-mail, of the To field; then after clicking on reply I have to remember to do a paste on top of the To field to put the list address there. I'm not sure why it works that way, but it does. Anyway, the point is that I know how to work around it; I just have to remember to do it. And in fact, the patch that's now included upstream is rather different from your patch. Yes, they took a different approach than I did. My patch applies to the mdsk_init_io internal function. It sets the return code to zero inside the function; so that the caller never sees a return code of 4. The official patch took a different approach. They changed the logic in the two places in the code where the return code is checked; so that it correctly handles a return code of 4. Both approaches work. The official patch is better, in my opinion, because it automatically sets the read-only option on when it detects the return code of 4 and also adds some diagnostic and informational messages. The down side to the official patch is that it does not backport as easily to old releases due to changes in the way that kernel messages are issued between 2.6.26 and 2.6.33. But both patches solve the problem. More confusion. The reason that still points to the Lenny version is that there has not yet been a release (upload) of D-I for Squeeze [1]. The images linked there are completely unusable to build CD images for Squeeze (and even unusable to install Squeeze). The only images relevant for Squeeze ATM are the daily built images available from [2], and they use the 2.6.30 kernel udebs from unstable. That's good info. Thank you. I was just about to try an install of Squeeze for s390. You just saved yourself a bug report. No, they accepted it as a *bug*. They did not accept your *patch*. Oh, now I get it. Sure. But OTOH it adds support for a class of devices that is currently effectively not supported. So even though the from a technical PoV it is a bug, from a functional PoV it can be seen as an enhancement. I don't think I understand what you are trying to say. Every DASD device which is supported by the DIAG driver, with or without the patch, is also supported by either the ECKD driver or the FBA driver. The only thing that the DIAG driver buys you that's useful is a performance boost. It might also help you if you have a vested interest in driving I/O through CP diagnose codes for some reason. (i.e. local modifications to DIAG 250 support in z/VM for accounting, security, auditing, or whatever.) The DIAG driver, with or without the patch, does not add support for devices that otherwise are not supported by Linux. And the patch does not add support for new devices. What the patch gives you is safety. Without the patch, the only way to share minidisks between multiple servers, and still use the DIAG driver, is to LINK the minidisks with access mode MW. And that gives multiple servers potential read/write access to the minidisk, which can (and almost certainly will) corrupt the minidisk if two servers mount the file system read/write at the same time. If the minidisks are LINKed with access mode R, that can't happen. CP prevents you from accidentally shooting yourself in the foot. But if you LINK the minidisk with access mode R, and you use the DIAG driver, you can't get the device online unless one of the two DIAG patches is on. Without the patch, you must either LINK the minidisk with access mode MW or else stay with access mode R but switch to the ECKD or FBA driver, depending on device type. If you use access mode MW, you increase the risk of corruption. If you switch to the ECKD or FBA driver, you lose the performance boost of the DIAG driver. I think it *is* worth the effort to try to
Re: Minidisk support (was: Installation Question)
Stephen Powell wrote: When I click on reply, the To field is pre-filled-in with the poster's e-mail address. So, it's a limitation of *your* email client. The choice of client is up to you, but forcing its limitations on others is backwards. I don't think I understand what you are trying to say. Every DASD device which is supported by the DIAG driver, with or without the patch, is also supported by either the ECKD driver or the FBA driver. The only thing that the DIAG driver buys you that's useful is a performance boost. OK. My s390 knowledge is very limited. My understanding was that minidisks were not supported at all (as there's a longstanding BR open to add support for them in the installer). This might increase the chances of getting it accepted for Lenny, but someone will still need to do the work to prepare things cleanly for the kernel team. *If* things are presented correctly I see no reason why the kernel team would not accept it. OK, I'll try. But in exchange, I'll ask that you attempt to persuade Eh, what? Why would I have to do that? I have no special status here. the kernel team to hold off on freezing Squeeze until a kernel with this patch on it is adopted by Squeeze. There isn't much point in going through the effort to get the patch into 2.6.32 if Squeeze is going to be frozen at 2.6.30 or 2.6.31. As 2.6.32 is already in unstable and Squeeze will only freeze in March, there is zero risk of that. If that had been a realistic risk, I would have mentioned it in earlier mails. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Minidisk support
On Tue, Dec 15, 2009 at 11:22:48AM -0500, Stephen Powell wrote:
Not being a registered Suse or Red Hat customer, I don't know if I
would have access to these backported fixes.
[...]
The Linux kernel is licensed under the GPL, so anyone who
distributes modified binaries is also obligated to make available
the source for their changes. Now as to where Red Hat and Suse
distribute their code, that I don't know.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
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)
On 2009-12-14, Adam Thornton wrote: On 2009-12-14, Stephen Powell wrote: Well, it's definitely a bug. But whether or not it affects a significant number of users is another story. This bug has been around since day 1 of the driver. And I'm apparently the first one to find it. So claiming that it affects a significant number of users would be a hard sell. Well, it bit me too, back when I was doing the diag250 driver for OpenSolaris, but I was too lazy to file a bug report on it, so, yeah, my bad. But two still isn't a lot, and I've changed jobs and don't work with s390x except for fun on Hercules these days. OK, I stand corrected. I'm not the first one to find it. But apparently, I'm the first one to report it. Others must have worked around it by linking the minidisks MW or by using another driver. Or maybe they wrote their own patches. But nobody reported it. That's one down side of having the source code. It's sometimes easier to fix it yourself and not report it. But then others don't benefit from your work. But since OpenSolaris is a competitor of Linux, I can see why, if they were paying you, that they didn't want you to spend your time filing Linux bug reports. -- 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)
On 2009-12-15, Frans Pop wrote: OK. My s390 knowledge is very limited. My understanding was that minidisks were not supported at all (as there's a longstanding BR open to add support for them in the installer). OK, now I think I understand where the confusion lies. I'd start a new thread here; but since the subject line already says minidisk support, and since that's exactly what we're discussing now, I'll just continue with the current thread. If you want to split this off into another thread, be my guest. I assume that you are referring to bug report number 447755, which I opened. (That reminds me, I opened it under my old e-mail address. I've got to get the e-mail address updated.) Please forgive me if I insult your intelligence or give too much information. That is not my intent. I have a tendency to do that at times, but I don't do it on purpose. I do respect you. I just don't know what you do know and what you don't know. So I'll just explain the whole thing and please politely ignore what you already know. We'll start with the definition of DASD. DASD is an acronym which stands for Direct Access Storage Device. It's a general term for any storage device in which the records can be easily accessed in random order, such as a disk. This is in contrast with a sequential access storage device, in which the records must be accessed in sequential order, such as a magnetic tape. Historically, DASD was not necessarily a disk device. In the early days of mainframes, there were magnetic drum devices as well, and they were also classified as DASD. But those devices fell by the wayside long ago. In today's environment, DASD and disk are practically, though not technically, synonymous. Mainframe DASD comes in two basic types: FBA (Fixed Block Architecture) and CKD (Count Key Data). FBA DASD is similar to the type of disk devices used in the world of PCs. The physical blocks on disk are all of a fixed size: 512 bytes. Sometimes you will see FBA DASD described as an FB-512 device. In theory, an FBA device can use other blocksizes; but to the best of my knowledge every FBA device ever made for mainframe use has a physical blocksize of 512. CKD DASD is different. With CKD DASD, the physical blocks on disk can be of all different sizes, from a theoretical minimum of 1 to a theoretical maximum of 65535 (hex ). In order to keep track of things, there is a special little block in front of every main block called a count block which contains the size (length) of the following main block, or data block. In addition, some types of blocks, such as directory blocks for partitioned data sets, also contain keys. The key is typically a sort key that is significant to the type of data being stored. In the case of a partitioned data set directory block, it is the key (member name) of the highest-sorting member (in the EBCDIC collating sequence) of all the members described in that directory block. Thus, for a keyed block, there are actually three blocks on the disk: a count block, a key block, and a data block. Most blocks do not have keys, they have only a count block and a data block. But in the general case, a block on this type of DASD device may have keys. Hence the name count-key-data or CKD DASD. In Linux, the FBA driver (the dasd_fba_mod kernel module) supports FBA devices and the ECKD driver (the dasd_eckd_mod kernel module) supports CKD devices. The E in ECKD stands for Extended. This refers to some extra channel commands supported by the control unit which allow some high-performance options, such as reading a whole track at a time, etc. But the underlying data format is still CKD. When people speak of ECKD DASD, what they mean is CKD-format DASD which has a control unit which supports the extra ECKD channel commands. Different IBM DASD devices are identified by a four-digit device-type number. For example, 3370, 9336, 9332, and 9335 are four different device types of FBA DASD. 9345, 3390, 3380, and 3350 are four different device types of CKD DASD. These different device types differ from each other in things like track capacity, number of tracks per cylinder, average seek time, average rotational delay, channel speed, etc. In addition to the main four-digit number, there is often a suffix to distinguish different models. These different models most often differ from each other only in the number of cylinders they possess. For example, a 3390-3, the most popular model of 3390, has 3339 cylinders, numbered from 0-3338. The 3390-9 has 10017 cylinders, numbered 0-10016. IBM has two main historical operating systems: VSE and MVS. VSE added support for FBA DASD, but MVS never did. MVS can only use CKD DASD. And since MVS is IBM's most popular (and most lucrative) operating system, CKD DASD is far more popular with mainframe customers than FBA DASD is. Of course, these days, hardly anybody uses real mainframe DASD anymore, be it FBA or CKD. Most mainframe customers
