Re: Minidisk support (was: Installation Question)
On Thursday 24 December 2009, Frans Pop wrote: > To start with: > - What device name does such a partition have? > - How could it be distinguished from a partitionable dasd? The output of the following command would be useful as well: # parted /dev/ print > Please send the replies for these questions to the BR instead of the > list! -- 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 Thursday 24 December 2009, Frans Pop wrote: > Stephen Powell wrote: > > "Partman does not recognize the pre-existing "partition" on disks > > which are pre-formatted in the CMS non-reserved format or the CMS > > reserved format." > > Right. That narrows it down a lot. Partman is almost exclusively shell > script, and is because of that relatively easy to play around with. Main > problem is that it's a *HUGE* amount of shell script, so the main > challenge is to find the correct place in the code. > > This should be fairly simple to solve. Hmmm. Possibly that info should come from libparted instead of partman itself. That would make it rather more difficult and probably beyond my skills. But we can give it a try. -- 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)
Stephen Powell wrote: > If I were to boil the problem definition down to one sentence it would > be: > > "Partman does not recognize the pre-existing "partition" on disks which > are pre-formatted in the CMS non-reserved format or the CMS reserved > format." Right. That narrows it down a lot. Partman is almost exclusively shell script, and is because of that relatively easy to play around with. Main problem is that it's a *HUGE* amount of shell script, so the main challenge is to find the correct place in the code. This should be fairly simple to solve. > Well, I'm working on it, but I'm not there yet. I am currently teaching > myself bash scripting by reading online tutorials and man pages. After > that, I'll probably tackle awk, perl, and sed. For this issue shell scripting (plus basic sed, find, etc.) is all that's needed. > What I have is a real mainframe, a legitimate z/VM license, and a > willingness to help. If you can provide me with *exact* info I need and if you can reply quickly, I may be able to add support for this. If you could provide me with access to a system that has these disks mounted that might work as well. To start with: - What device name does such a partition have? - How could it be distinguished from a partitionable dasd? Please send the replies for these questions to the BR instead of the list! -- 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-24, Frans Pop wrote: > Here's one of the reason why I cannot do anything about this: I only have > access to Hercules running Linux, so I cannot create CMS formatted disks. Well, there are copies of very old releases of VM out there, such as VM/370 Release 6. VM/370 Release 6 has passed into the public domain now. But it is useless for this purpose. VM/370 Release 6 does not support the modern EDF disk format, with blocksizes of 512, 1024, 2048, and 4096. It only supports the original CDF format, with a blocksize of 800. That format is now obsolete, and Linux does not support it. It is technologically possible to run modern releases of z/VM under Hercules. I have heard that some people have done a Disaster Recovery Test of a modern z/VM system under Hercules. The problem is licensing. z/VM is not free software: you have to license it from IBM. And IBM normally won't license z/VM to run under Hercules, except maybe by special bid. And if they do license it to you by special bid, they'll probably charge you enough that it will be cheaper to buy a real mainframe and run it there! But I think IBM has, or used to have, some mainframes that have been set up for Linux developers to use, and they give away time and space on the machines for those who qualify. You might check into that. It would be nice if someone were to write a program that runs under Linux that can format a DASD device in the CMS format. That would help. As far as I know, there's no such program today. On 2009-12-24, Frans Pop wrote: > Why? It has the eckd kernel driver which supports all four formats if I > understand you correctly. The fact that you cannot do a low-level CMS > format is IMO not relevant as the first thing should be to support > pre-formatted disks anyway. Yes, that's true. I'm not asking for support for doing a low-level format in CMS format while the Debian installer is running. That would be wonderful, but even Suse doesn't give me that. All I'm asking for right now is the capability to use pre-formatted CMS disks. On 2009-12-24, Frans Pop wrote: > So what exactly is missing there? At what point does it go wrong: is it in > s390-dasd, or is it in partman? I still don't get it... I'm going from memory here. I haven't done an install in quite a while. But if I recall correctly, there is an initial screen in which the dasd devices that it finds are listed, and you can pick which ones you want to use. That works fine. Then there is a second screen after that on which you can do things like create partitions and assign mount points. I think that's partman. The problem is that a disk in CMS FORMAT, reserved or non-reserved, is treated like an unformatted disk. Partman does not recognize that the disk already has a "partition" on it. Therefore, I cannot assign a mount point to it or designate it as swap space. It will not let me do anything with the disk unless it runs dasdfmt and fdasd on it first. Then, and only then, does it recognize a "partition" on the disk, which I can assign a mount point to or designate as swap space. But that destroys the pre-existing CMS format which I need to keep. If I were to boil the problem definition down to one sentence it would be: "Partman does not recognize the pre-existing "partition" on disks which are pre-formatted in the CMS non-reserved format or the CMS reserved format." > It also still seems to me that anybody who > *does* have access to such devices should be able to implement basic > support, even without much coding skills. Well, I'm working on it, but I'm not there yet. I am currently teaching myself bash scripting by reading online tutorials and man pages. After that, I'll probably tackle awk, perl, and sed. And then eventually, C. I'm heading in the right direction. Maybe someday I'll be useful to you. But Rome wasn't built in a day. I'm sorry if the problem description wasn't clear to you. It was clear to me. But understanding a problem is one thing. Being able to explain it to someone else who comes from a different background and a different perspective is another thing. That takes work. And apparently I'm not as good at that as I thought I was. What I have is a real mainframe, a legitimate z/VM license, and a willingness to help. What I lack but am working on is Linux programming skills. I think I will eventually have them, but I'm not there yet. What I don't have, and likely never will, is FBA DASD. Someone else will need to test that support. You might be able to create emulated FBA dasd devices under Hercules. But formatting them in CMS format (EDF CMS format) is another story. In the meantime, if there's anything I *can* do for you, let me know. Merry Christmas! -- 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)
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. Debian installer includes 2 drivers: - dasd_fba_mod - dasd_eckd_mod The second one is the one that's normally loaded AFAIK, so that means all four formats should be supported. > 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 Here's one of the reason why I cannot do anything about this: I only have access to Hercules running Linux, so I cannot create CMS formatted disks. > The issue in 447755 is that the Debian installer only supports > cdl format. Why? It has the eckd kernel driver which supports all four formats if I understand you correctly. The fact that you cannot do a low-level CMS format is IMO not relevant as the first thing should be to support pre-formatted disks anyway. High level formatting (partitioning and file system creation) is not an issue here. Once the basic device is recognized, that should be automatic (unless the device has a special naming convention that's not recognized by partman, but that is trivial to implement). The s390-dasd udeb takes care of identifying available channels. Are minidisks maybe not listed as ccw channels maybe, or are they of a special type? The s390-dasd C program is relatively simple: it's a state engine and all actual functionality is based in info from /sys/. So what exactly is missing there? At what point does it go wrong: is it in s390-dasd, or is it in partman? I still don't get it... > And since this is the only format that the DIAG > driver *doesn't* support, the DIAG driver cannot be used, even > after installation, without migrating the data to other minidisks > after the installation. The installer currently does not include the DIAG driver. I'm not sure why, but possibly to avoid having to choose between two different drivers supporting the same device. But if the ECKD driver really does support all formats, then shouldn't you be able to use that initially and then switch over to DIAG after the installation? If so, missing DIAG in the installer would be no huge issue. > There is also another issue mentioned in 447755, and that is > a problem with mounting devices in the wrong order. In hindsight, > I should have created two separate bug reports: one for the lack > of support for CMS minidisks and one for the mount order issue. You can still do that... > I apologize for the long reply, but again; I don't know what > you know and what you don't know. Well, the thing this has clarified most for me is that my original position is still correct: I cannot do anything about this as the problem is not clear. Especially without access to a CMS formatted minidisk I cannot even start to see what's missing. It also still seems to me that anybody who *does* have access to such devices should be able to implement basic support, even without much coding skills. And they could at least specify *in detail* what's missing by doing all the needed steps manually: - what kernel modules are involved? - what are the relevant files in /sys/ and what are their contents? - what must be done to activate a device? - does the kernel recognize the device (see dmesg)? - do device nodes get created for the device? - ... If a kernel module is missing, simply scp it from an installed system into the D-i environment, run 'depmod -a', modprobe it and it should work. Working on Debian Installer is not rocket science, really. > As an official Debian developer, you carry more weight than I do. > I can appeal to the kernel team, of course; but if you say I'm > full of excrement, they'll believe you more than they will me. No really, I do not have *any* influence over this. Even the kernel team does not have that much influence over the release date. Things just slowly move towards the critical mass needed to release, and at that point only serious release critical issues can stop it. And this simply does not qualify. So what you should do is just work to get any pet issues fixed in time and not make a huge issue of things. That's exactly the same basis on which everybody works. There's *plenty* of time to get it done. You just have to make it happen. Cheers, FJP -- To UNSUBSCRIBE, email to debian-s390-
Re: Minidisk support (was: Installation Question)
Stephen Powell wrote: > Pardon my ignorance, but would you mind giving me the full URL of the > upstream linux-s390 mailing list, so that I can follow-up on your advise? How about the mail address instead? You don't need to be subscribed; you'll be CCed on replies by default. The address is: linux-s390 *AT* vger.kernel.org Most kernel mailing lists can be found at: http://vger.kernel.org/vger-lists.html The people maintaining the stable updates can be reached at stable *AT* kernel.org You can either CC them in your request, or leave it up to the s390 maintainers to contact them. Make sure you include the git commit ID and preferably the patch author and description in your request. Cheers, FJP -- 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, Frans Pop wrote: > By far the best way is to try to get *upstream* to include the patch in one > of their "stable updates" for .32, so in 2.6.32.1 or 2.6.32.2. I would > suggest proposing that on the linux-s390 mailing list. Pardon my ignorance, but would you mind giving me the full URL of the upstream linux-s390 mailing list, so that I can follow-up on your advise? A quick search of the internet yielded a number of hits, but nothing obviously the right place in the first few screens. -- 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: 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)
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 cus
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)
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 (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 thin
Re: Minidisk support (was: Installation Question)
On Dec 14, 2009, at 3:44 PM, 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. Adam
Re: Minidisk support (was: Installation Question)
On Monday 14 December 2009, Frans Pop wrote: > Stephen Powell wrote: > > I *did* ask the kernel team. > > Yes, and I gave several reasons that could explain why they may not have > replied. P.S. I never meant to imply that anything you did was wrong. I was just trying to explain why it was not effective. Obviously it would have been much better if the kernel team had replied to your bug report themselves. But things become much easier if you try to look at things from their PoV. -- 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)
Stephen Powell wrote: > My private e-mail sees the e-mail as coming from the poster, not from the > list. 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. Note that different communities have different rules. For upstream kernel mailing lists for example the policy is to CC everybody to whom the mail you reply to was addressed. > "Hijack" is a strong word. In its original meaning: sure. But it's an accepted term in this context. http://www.urbandictionary.com/define.php?term=thread+hijacking http://www.google.com/search?hl=en&q=hijack+thread+mail&aq=f&oq=&aqi= > I *did* ask the kernel team. Yes, and I gave several reasons that could explain why they may not have replied. > Since upstream development has accepted this as a bug and has agreed to > provide a fix in the next merge window, I respectfully request that > this patch be included in the next stable release of Debian for s390 > (6.0.0 -- Squeeze). If you could include it in the next update of the > stable release (5.0.4 -- Lenny), that would be good too. Sure, but the core issue that your patch was at that time not accepted upstream still stands. And in fact, the patch that's now included upstream is rather different from your patch. > Hmm. Starting with the top directory of the Debian archive, > > dists/squeeze/main/installer-s390/current [...] > etc. are all pointing to the Lenny version of the Debian installer. > When the installer is used, either to install or in a rescue mode, > this is the kernel that is running. It may *install* a newer kernel, > when it is actually performing an install; but the kernel that is > *running* comes from the image files listed above. 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. > And that's why I asked. I actually was trying to accomplish two things: > (1) I thought that the primary maintainer for the s390 version of the > Debian installer would be in a position to know whether the next point > release (though I didn't call it that) was going to include an > s390-specific update to something as basic as a DASD driver, and Not if there's not a kernel update for Lenny that includes the fix first. > (2) If > you didn't know about the fix I wanted to make you were aware of it so > that you would include the update to the installer kernel in the next > point release. As there is no separate installer kernel, that question is unanswerable. >> The kernel team policy is to only include patches that already >> have been accepted upstream or look certain to get included upstream >> very soon. > > I figured as much. And that's why I mentioned that upstream had accepted > it. No, they accepted it as a *bug*. They did not accept your *patch*. >> This patch is IMO more an enhancement than a bug fix, so I'm not certain >> it qualifies for a stable update. > > I disagree. It's definitely a bug, not an enhancement. 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. > The rest of the post is mostly about suggestions for how to get this into > the 2.6.32 vs the 2.6.33 kernel. Thank you for the suggestions. I'll > keep this information for future reference. But since nobody seems to > care but me, I'm not sure it's worth it. I think it *is* worth the effort to try to get the fix in 2.6.32, but probably not in Lenny. > If the kernel team had simply stated their policy for including > updates in a stable point release in a reply to Debian bug report 550898, > and telling me it did not qualify based on those criteria, > they would have saved both of us a lot of time. It is somewhat documented here: http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines Cheers, FJP [1] A D-I release is long overdue. [2] http://www.debian.org/devel/debian-installer/ -- 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)
First of all, thank you very much for your lengthy reply. I am honored that you took the time to explain so many things. However, I believe that you have some misconceptions as well. > (No need to CC me; I read the list; see the Debian mailing list policy.) Here is the exact wording from the mailing list policy: When replying to messages on the mailing list, do not send a carbon copy (CC) to the original poster unless they explicitly request to be copied. Strictly speaking, I did not do that. I am subscribed to the list; and whenever a post is made, I get a copy in my private e-mail. My private e-mail sees the e-mail as coming from the poster, not from the list. As viewed by my e-mail system, I was replying to a private e-mail from you. It was the list that I added to the CC, for the benefit of others. Nevertheless, I acknowledge that the net result is the same. In the future, I will try to remember to change the TO field from the poster's address to the list address instead of adding the list address to the CC list, unless I know that the poster is not subscribed to the list or he explicitly requested a CC. By the way, there's another item on the mailing list policy that may interest you: If you want to complain to someone who sent you a carbon copy when you did not ask for it, do it privately. > please don't hijack an existing thread for an unrelated > issue; next time, please just start a new thread instead. Well, to you it may seem unrelated; but to the way I was thinking at the time, it was related. User A was asking if fix X was going to be included in the next update and user B (me) was chiming in to ask if fix Y was going to be included as well. I defer to your judgment on this matter, but please keep things in perspective. This list has a very low posting rate. Here we are in the middle of December, and this is the first legitimate thread, not counting spam, that has been posted this month. I wouldn't be surprised if it's the only thread at the end of the month (except for the fact that you forced a new thread). I doubt that people are going to have trouble keeping everything straight. "Hijack" is a strong word. When I think of hijack, I think of the terrorists who hijacked those planes and flew them into the World Trade Center. Hijacking is criminal activity. If you think a reply belongs in a new thread, please just start one yourself in the reply. > You are mixing two different things in this mail: > - the next stable release (Squeeze) > - the next update (point release) for the existing stable release (Lenny) > > The rules, limitations and methods for getting changes included are > completely different for them, and you should clearly separate between > them. OK, maybe I don't know all of the Debian-internal-use-only terminology. Apparently, what I should have said is "stable point release" instead of "stable release update". By "stable release update", I meant an update to the stable release, that is, an update to Lenny. I did not mean "Squeeze becoming the stable release". Sorry for the confusion. > The people to ask are the kernel team. I *did* ask the kernel team. Debian bug report 550898 was reported against package linux-image-2.6.26-2-s390x. The maintainer for package linux-image-2.6.26-2-s390x is Debian Kernel Team . Here is part of what I said in my last post: Since upstream development has accepted this as a bug and has agreed to provide a fix in the next merge window, I respectfully request that this patch be included in the next stable release of Debian for s390 (6.0.0 -- Squeeze). If you could include it in the next update of the stable release (5.0.4 -- Lenny), that would be good too. In the meantime I will need to build a custom kernel with every security update that hits the kernel, which I don't like to have to do. As I read over this again, I now realize that I used internally inconsistent terminology, which may have added to the confusion. Nevertheless, I did mention both Squeeze and Lenny as releases that I would like to see updated. But there was no response. > There is no difference between regular and D-I kernels, especially not for > the next stable release. D-I merely repackages the regular kernel into > udebs it does not build its own kernels. > So, any change included in the regular kernels almost automatically gets > included in the installer (except when it requires additional new kernel > modules to be included, which is not the case here) Hmm. Starting with the top directory of the Debian archive, dists/squeeze/main/installer-s390/current is a symbolic link to ../../../lenny/main/installer-s390/current so right now the boot-up files that I use to install, which are dists/squeeze/main/installer-s390/current/images/generic/kernel.debian dists/squeeze/main/installer-s390/current/images/generic/initrd.debian dists/squeeze/main/installer-s390/current/images/generic/parmfile.debian etc. are all pointing t
