Donald, You could check that you are not inadvertently using a file system, lvm or swap on an entire dasd instead of in a partition. If you are, typical symptoms could be seeing "e5", for example, if a process SIGSEGV'd Registers: r0 e5e5e5e5e5e5e5e5 r1 0000000086ddccb8 r2 0000000086dda218 r3 e5e5e5e5e5e5e5e5 r4 e5e5e5e5e5e5e5e5 r5 0000000000000000 r6 0000000085cc6ac0 r7 000000010003d920
The chars "x'E5" (EBCDIC "V") which is seen may be used by ZVM to "clear" unused memory. In Linux on System z the first 2 tracks of any ECKD dasd are used for the disk layout. When you partition an ECKD dasd the first track to be used for any partition is the third track. Track 0 and track 1 are accessible by the device I/F /dev/dasdbm and the device /dev/dasdbm1 begins with track 2. Any record of track 0 and track 1 is patterned with 'E5', when read from disk into memory. In case of a write request (to disk) only the record length is written back, which can also lead to problems. Mike O'Reilly IBM Linux Change Team Donald Russell <russell.don@gmai l.com> To Sent by: Linux on LINUX-390@vm.marist.edu, 390 Port cc <linux-...@vm.mar ist.edu> Subject file corruption on RHEL 5.8 10/02/2013 10:17 AM Please respond to Linux on 390 Port <linux-...@vm.mar ist.edu> RHEL 5.8 zLinux on zVM 6.1 using ECKD disks We have a recurring problem where files get corrupted. It always happens in the same directory, and we always wind up running fsck in single user mode to get the file system back together. The file system is EXT-2. (We changed from EXT-3 on this FS due to numerous journaling errors which caused the FS to go to RO mode) In the case I'm currently working on, a ".so" file (binary) has a chunk of plain text in the middle of it. The "chunk" is 4K bytes long, and is a piece of a program listing. 4K is the block size of the underlying DASD. I am now in the process of trying to find when this happened by restoring backup copies and seeing if I can narrow the time frame down. Obviously I don't expect a "do this to fix the problem", but what I'm wondering is, has anybody else encountered this? What could cause a block in the middle of the file to be overwritten this way? Are there any tools I can run (preferably while the system is at runlevel 3 or 5) to check if two (or more) files are using the same block in a file? I envision a "bad block pointer" somewhere, but how does that happen? I'm considering converting the file system to EXT-4... I don't think there's a conversion per-se, I'd create a new EXT-4 FS then copy all the files from the EXT2 FS to the EXT-4 one. Any suggestions/help are greatly appreciated. Thank you, Donald Russell ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/ ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
<<inline: ecblank.gif>>
<<inline: graycol.gif>>
<<inline: pic54843.gif>>