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 get the fix in 2.6.32, but
> probably not in Lenny.
OK, I'll try. But in exchange, I'll ask that you attempt to persuade
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.
Reply to: