Hi Mark, I got a ton of I/O errors when I tried to mount the R/O ext3 as ext2 - BUT in fairness, that may have been because the owner was up and running and had the disk R/W. May as well keep it ext2 for consistency across the boards.
Xip2fs looks very cool, I'll have to play with that at some point. -Mike -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Post, Mark K Sent: Thursday, May 26, 2005 2:15 PM To: [email protected] Subject: Re: Debian R/O DASD Errors Michael, The point being that if the maintenance machine has it R/W, no other system should be using it at that time. Once the maintenance machine umounts the file system and is shut down and logged off VM, then the other systems can mount it. I mount ext3 file systems as ext2 all the time. I've never had a problem with it. What error(s) did you get when you tried it? If you want to share stuff across guests, the xip2fs method would work best for you, all the way around. Mark Post -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Coffin Michael C Sent: Thursday, May 26, 2005 1:35 PM To: [email protected] Subject: Re: Debian R/O DASD Errors Hi Mark, The intent is not to have the 'MAINTenance userid' that has them linked R/W up and running all the time, so they should be fine R/O. But I do agree having them as ext3 is asking for trouble, particularly when the MAINTenance machine is up. Unfortunately, you can't just mount an ext3 filesystem as ext2 - at least it didn't work when I tried it. So I converted the filesystem to ext2 using tune2fs/e2fsck - THAT was a lot of fun! Ultimately I got it straightened out so now /usr and /usr/opt are ext2, the MAINTenance id mounts them r/w when needed, the servers that link r/o now report no errors with the disks when they start (unles the MAINTenance id has them r/w, but even then the other servers still do come up OK). It's all working now. :) I'd love to give all of my servers R/W /usr - but in our shop, that's a LOT of DASD - and moreover it's a LOT of DASD to backup for no good reason when 99% of the content is the same as every other server's. The R/O shared disk link is best for our shop all things considered, one disk (well, two since we spin /usr/opt off as well) to maintain and backup (and restore in a DR situation). -Mike -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Post, Mark K Sent: Thursday, May 26, 2005 12:45 PM To: [email protected] Subject: Re: Debian R/O DASD Errors Michael, It's been pretty well settled for some time now that you cannot have one guest running with a disk R/W, and try to share it with others R/O. It's just asking for trouble, such as you're seeing. Any and all systems that have it LINKed and mounted, must have it R/O. Also, mounting an ext3 file system R/O doesn't make any sense. Mount it as ext2, then it won't even try to find the journal to replay it. In addition to having the CP LINKs to the disk be R/O, make sure that your kernel parms have dasd=www,xxx(ro),yyy-zzz specified for the disk(s) that are R/O. Mark Post -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Michael Coffin Sent: Thursday, May 26, 2005 9:18 AM To: [email protected] Subject: Debian R/O DASD Errors Hi Folk, I have two Debian 2.4.17 Linux390 systems, configured with ext3 filesystems as follows: DEBIBASE (an image with full r/w DASD, used to maintain /usr and /usr/opt): MDISK 150 3390 1839 750 LINUX1 MR / MDISK 151 3390 3139 200 LINUXA MR <swap> MDISK 152 3390 1 3338 LINUXE MR /usr MDISK 156 3390 1 3338 LINUXG MR /usr/opt DEBPROD1 (an image with R/O links to /usr and /usr/opt): LINK DEBIBASE 0152 0152 RR * SHARED R/O /USR LINK DEBIBASE 0156 0156 RR * SHARED R/O /USR/OPT MDISK 150 3390 2089 750 LINUX5 MR / MDISK 151 3390 139 200 LINUX6 MR <swap> When I bring up DEBIBASE (full R/W DASD) it comes up clean, no problems. When I bring up DEBPROD1 (R/O /usr) and DEBIBASE is running - I get the following errors on the 152 R/O link (dasdc) which loop forever, DEBPROD1 never starts: Checking root file system... fsck 1.27 (8-Mar-2002) /dev/dasd/0150/part1: clean, 8203/67520 files, 112808/134976 blocks EXT3 FS 2.4-0.9.16, 02 Dec 2001 on dasd(94,1), internal journal Calculating module dependencies... done. Loading modules: Checking all file systems... fsck 1.27 (8-Mar-2002) /dev/dasd/0152/part1: recovering journal dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: EXAMINE 24: Command Reject detected - fatal error dasd(eckd): Sense data: dasd(eckd):device 0152 on irq 15: I/O status report: dasd(eckd):in req: 07fde100 CS: 0x00 DS: 0x02 dasd(eckd):Failing CCW: 07fde1a0 dasd(eckd):Sense(hex) 0- 7: 80 02 00 00 36 06 06 00 dasd(eckd):Sense(hex) 8-15: 00 00 00 ab 51 00 00 05 dasd(eckd):Sense(hex) 16-23: 21 00 58 14 44 00 00 00 dasd(eckd):Sense(hex) 24-31: 00 00 4c e2 00 00 06 06 dasd(eckd):24 Byte: 0 MSG 0, no MSGb to SYSOP dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: (EXAMINE) ERP chain report for req: 07fde100 dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: 07fde100: c5c3d2c4 07e91f00 07e91f00 074eac00 dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: 07fde110: 07fdd000 07fab400 07fde190 03000002 dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: 07fde120: 00000000 ff000000 07fde170 00000000 dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: 07fde130: 00000000 00000000 0000011e 1a300000 dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: 07fde140: bd11128a bab6ca80 bd11128a bae54f00 dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: 07fde150: 00000000 00000000 00000000 00000000 dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: 07fde160: 00000004 00000020 00546b7c 00000000 dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: Channel program (complete): dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: 07fde190: 63400010 07fde170 47400010 07fde180 dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: 07fde1a0: 85001000 07a45000 00000000 00000000 dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: 07fde1b0: 00000000 00000000 00000000 00000000 dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: 07fde1c0: 00000000 00000000 00000000 00000000 dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: Failed CCW (07fde1a0) already logged end_request: I/O error, dev 5e:09 (dasd), sector 4224 And finally, if I bring up DEBPROD1 (R/O /usr) while DEBIBASE is NOT logged on/running - I get the following errors on 152 and 156 - BUT it doesn't loop forever and DEBPROD1 DOES eventually come up: Checking root file system... fsck 1.27 (8-Mar-2002) /dev/dasd/0150/part1: clean, 8203/67520 files, 112808/134976 blocks EXT3 FS 2.4-0.9.16, 02 Dec 2001 on dasd(94,1), internal journal Calculating module dependencies... done. Loading modules: Checking all file systems... fsck 1.27 (8-Mar-2002) /dev/dasd/0152/part1: clean, 100241/300960 files, 559162/600816 blocks dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: EXAMINE 24: Command Reject detected - fatal error dasd(eckd): Sense data: dasd(eckd):device 0152 on irq 15: I/O status report: dasd(eckd):in req: 07e91f00 CS: 0x00 DS: 0x02 dasd(eckd):Failing CCW: 07e91fa0 dasd(eckd):Sense(hex) 0- 7: 80 02 00 00 36 03 0e 00 dasd(eckd):Sense(hex) 8-15: 00 00 00 9b 51 00 00 05 dasd(eckd):Sense(hex) 16-23: 21 00 58 14 44 00 00 00 dasd(eckd):Sense(hex) 24-31: 00 00 4c e1 00 00 03 0e dasd(eckd):24 Byte: 0 MSG 0, no MSGb to SYSOP dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: (EXAMINE) ERP chain report for req: 07e91f00 dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: 07e91f00: c5c3d2c4 00000000 07e91f00 07e91f00 dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: 07e91f10: 07fdd000 07fab400 07e91f90 03000002 dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: 07e91f20: 00000000 ff000000 07e91f70 00000000 dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: 07e91f30: 00000000 00000000 0000011e 1a300000 dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: 07e91f40: bd11138e e7b10540 bd11138e e7b11480 dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: 07e91f50: 00000000 00000000 00000000 00000000 dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: 07e91f60: 00000004 00000020 00546b7c 00000000 dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: Channel program (complete): dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: 07e91f90: 63400010 07e91f70 47400010 07e91f80 dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: 07e91fa0: 85001000 07a45000 00000000 00000000 dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: 07e91fb0: 00000000 00000000 00000000 00000000 dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: 07e91fc0: 00000000 00000000 00000000 00000000 dasd_erp(3990): /dev/dasdc ( 94: 8),[EMAIL PROTECTED]: Failed CCW (07e91fa0) already logged end_request: I/O error, dev 5e:09 (dasd), sector 4224 /dev/dasd/0156/part1: clean, 30314/300960 files, 220225/600816 blocks dasd_erp(3990): /dev/dasdg ( 94: 24),[EMAIL PROTECTED]: EXAMINE 24: Command Reject detected - fatal error dasd(eckd): Sense data: dasd(eckd):device 0156 on irq 16: I/O status report: dasd(eckd):in req: 07fde100 CS: 0x00 DS: 0x02 dasd(eckd):Failing CCW: 07fde1a0 dasd(eckd):Sense(hex) 0- 7: 80 02 00 00 40 03 0e 00 dasd(eckd):Sense(hex) 8-15: 00 00 00 9b 51 00 00 05 dasd(eckd):Sense(hex) 16-23: 21 00 58 14 44 00 00 00 dasd(eckd):Sense(hex) 24-31: 00 00 4c e1 00 00 03 0e dasd(eckd):24 Byte: 0 MSG 0, no MSGb to SYSOP dasd_erp(3990): /dev/dasdg ( 94: 24),[EMAIL PROTECTED]: (EXAMINE) ERP chain report for req: 07fde100 dasd_erp(3990): /dev/dasdg ( 94: 24),[EMAIL PROTECTED]: 07fde100: c5c3d2c4 00000000 07fde100 07fde100 dasd_erp(3990): /dev/dasdg ( 94: 24),[EMAIL PROTECTED]: 07fde110: 07fd5000 07fa1b00 07fde190 03000002 dasd_erp(3990): /dev/dasdg ( 94: 24),[EMAIL PROTECTED]: 07fde120: 00000000 ff000000 07fde170 00000000 dasd_erp(3990): /dev/dasdg ( 94: 24),[EMAIL PROTECTED]: 07fde130: 00000000 00000000 0000011e 1a300000 dasd_erp(3990): /dev/dasdg ( 94: 24),[EMAIL PROTECTED]: 07fde140: bd11138e eedbcd80 bd11138e eedbdc40 dasd_erp(3990): /dev/dasdg ( 94: 24),[EMAIL PROTECTED]: 07fde150: 00000000 00000000 00000000 00000000 dasd_erp(3990): /dev/dasdg ( 94: 24),[EMAIL PROTECTED]: 07fde160: 00000004 00000020 00546b7c 00000000 dasd_erp(3990): /dev/dasdg ( 94: 24),[EMAIL PROTECTED]: Channel program (complete): dasd_erp(3990): /dev/dasdg ( 94: 24),[EMAIL PROTECTED]: 07fde190: 63400010 07fde170 47400010 07fde180 dasd_erp(3990): /dev/dasdg ( 94: 24),[EMAIL PROTECTED]: 07fde1a0: 85001000 079cb000 00000000 00000000 dasd_erp(3990): /dev/dasdg ( 94: 24),[EMAIL PROTECTED]: 07fde1b0: 00000000 00000000 00000000 00000000 dasd_erp(3990): /dev/dasdg ( 94: 24),[EMAIL PROTECTED]: 07fde1c0: 00000000 00000000 00000000 00000000 dasd_erp(3990): /dev/dasdg ( 94: 24),[EMAIL PROTECTED]: Failed CCW (07fde1a0) already logged end_request: I/O error, dev 5e:19 (dasd), sector 4224 Setting kernel variables. Loading the saved-state of the serial devices... Mounting local filesystems... /dev/dasd/0152/part1 on /usr type ext3 (ro) /dev/dasd/0156/part1 on /usr/opt type ext3 (ro) So what gives? What's Debian doing to the R/O DASD that's causing these errors, and why is it that when the owner (DEBIBASE) is up with the disk R/W, DEBPROD1 linked R/O loops forever on the I/O error, but not when DEBIBASE is down? Hopefully the above records won't "wrap" in your email client (hint: turn "wrap" off). I had attached the consoles (containing a bit more data as well) as plain text attachments, but the Marist listserve rejected the post - contact me off-list if interested and I'll send them to you directly. Michael Coffin, President MC Consulting Company, Inc. PMB 123 289 Park Street Stoughton, Massachusetts 02072 Voice: (781) 344-9837 FAX: (781) 344-7683 [EMAIL PROTECTED] www.mccci.com We employ aggressive SPAM filters. If you cannot reply or send email to mccci.com go to www.mccci.com/spamblockremove.php ---------------------------------------------------------------------- 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 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 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 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 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
