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>>
