On Wednesday 12 February 2003 06:09, Juan Antonio Vera wrote: > Hi all. > > I work with kernel 2.4.20 , lvm 1.0 and jfsutils 1.1.1. for 2 weeks > and I had 3 or 4 problems with jfs filesystems. The problems > basically happened > when I worked with office aplications (StarOffice) or copy files > between jfs filesystems. The last problem was very serious becasuse > I've to push reset button to recuperate the system control and I lost > one filsystem. In this last case, the root filesystem begins to > report problems about jfs boundaries and > I press reset button. On reboot, there was one filesystem that jfs > can't recuperate. This is my fsck.jfs output.
The damage to the volume looks extensive. Is it possible that the LVM volume modified in some harmful way? /var/log/messages indicates problems with the block map. I see an opportunity to do better damage control. When the first problems were detected, JFS should mark the superblock dirty instead of just causing a BUG. This would force fsck to try to fix the volume earlier before more damage could be done. I don't know what caused the earlier problems. I haven't seen a report of the first assert() before. I've got several things to look at this morning, so I may not get to this one immediately. > > gava:~# fsck.jfs -v -a /dev/dades_vg/aplicacions > fsck.jfs version 1.1.1, 17-Dec-2002 > The current device is: /dev/dades_vg/aplicacions > (chklog) FSCK Open(...READ/WRITE EXCLUSIVE...) returned rc = 0 > > (chklog) FSCK Primary superblock is valid. > > (chklog) FSCK The type of file system for the device is JFS. > > Block size in bytes: 4096 > File system size in blocks: 90112 > Phase 0 - Replay Journal Log > (chklog) FSCK:LOGREDO: Log already redone! > > (chklog) FSCK logredo returned rc = 0 > > Phase 1 - Check Blocks, Files/Directories, and Directory Entries. > (chklog) FSCK Dense file (inode A16) has an unallocated section > after offset 16. I haven't seen this before. > (chklog) FSCK Primary metadata inode A16 is corrupt. > > (chklog) FSCK Duplicate reference to 2 block(s) beginning at offset > 42 found in file system object MA16. This is bad. > Errors detected in the primary File/Directory Allocation Table. > Errors detected in the secondary File/Directory Allocation Table. > CANNOT CONTINUE. > (chklog) FSCK processing terminated: 2/12/2003 14.18.57 with > return code: -10049 exit code: 4. This looks like it's beyond fixing. You may be able to recover data from it by mounting read-only. > I'm worry about jfs stability because I'm evaluating journaling > filesystems and I hear good things about it. The stability is getting better, and a lot of people are having no problems at all, but we're still getting a few reports like yours. > Any idea about my problems ??. Not yet, but as I stated above, we may be able to mark the filesystem dirty earlier to help contain the damage. > > Thanks in advanced. Thanks for the information. Shaggy -- David Kleikamp IBM Linux Technology Center _______________________________________________ Jfs-discussion mailing list [EMAIL PROTECTED] http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jfs-discussion
