Dave, A quick update on this issue.. I've run jfs_fsck repairs several more times on this file system and each time one more file is deleted due to cross linked blocks. All the files in question were created on the same day and at least 2 of the 3 recent files were corrupt *before* they were deleted. I've since checked all the files created on the same day and 4 out of 1,267 are corrupt. This gives me hope that running jfs_fsck 4 more times will fix the file system. It would be faster to just go in and remove the corrupt files by hand but since the file system is marked dirty I can only mount it read-only.. Is there a way to force it to be read-write? If this is possible, how dangerous would it be to remove the 4 corrupt files manually?
Thanks, Tim On Jul 19, 2012, at 3:18 PM, Dave Kleikamp <[email protected]> wrote: > On 07/19/2012 12:09 PM, Tim Nufire wrote: >> Dave, >> >> Running jfs_fsck a third time yielded yet another file with cross linked >> blocks in the same directory as before. The directory in question has 4 more >> files in it, 2 of which are corrupt and 2 are good.... I also found 2 files >> in lost+found that are perfectly good and can be recovered. Is it better to >> just save the good files, delete the directory and recreate it or keep >> running jfs_fsck until it comes back clean? >> > It's very strange that each instance is complaining about the same > duplicate block: 4248749952, although it sees it in different files. > > I can't really explain what's going on here, so I'm not sure what the > best strategy is. I'd advise backing up any important data to another > filesystem or media. You should be able to mount it read-only. > >> Here's the output from the last repair: >> >> /sbin/jfs_fsck version 1.1.15.patched.2011.03.07, 04-Mar-2011 >> processing started: 7/18/2012 15:08:55 >> The current device is: /dev/md10 >> Open(...READ/WRITE EXCLUSIVE...) returned rc = 0 >> Primary superblock is valid. >> The type of file system for the device is JFS. >> Block size in bytes: 4096 >> Filesystem size in blocks: 4756914448 >> **Phase 0 - Replay Journal Log >> LOGREDO: Log already redone! >> logredo returned rc = 0 >> **Phase 1 - Check Blocks, Files/Directories, and Directory Entries >> Duplicate reference to 1 block(s) beginning at offset 4248749952 found in >> file system object FF4086930. >> Inode F4086930 has references to cross linked blocks. >> File system object FF4086930 has corrupt data (39). >> **Phase 2 - Count links >> **Phase 3 - Duplicate Block Rescan and Directory Connectedness >> Duplicate reference to 1 block(s) beginning at offset 4248749952 found in >> file system object FF4086930. >> Inode F4086930 has references to cross linked blocks. >> **Phase 4 - Report Problems >> File system object FF4086930 is linked as: >> /20120713/08/08886904e6bbb5a731290014/h10/bzmf2108886904e6bbb5a7312900140000000000000000201207131031480000000240116.bzmf >> File claims cross linked block(s). >> cannot repair FF4086930. Will release. >> **Phase 5 - Check Connectivity >> **Phase 6 - Perform Approved Corrections >> Superblock marked dirty because repairs are about to be written. >> Directory inode F4086922 entry reference to inode F4086930 removed. >> Storage allocated to inode F4086930 has been cleared. >> **Phase 7 - Rebuild File/Directory Allocation Maps >> **Phase 8 - Rebuild Disk Allocation Maps >> Filesystem Summary: >> Blocks in use for inodes: 2512268 >> Inode count: 20098144 >> File count: 11226659 >> Directory count: 2153660 >> Block count: 4756914448 >> Free block count: 561778219 >> 19027657792 kilobytes total disk space. >> 6911782 kilobytes in 2153660 directories. >> 16769563037 kilobytes in 11226659 user files. >> 0 kilobytes in extended attributes >> 0 kilobytes in access control lists >> 17893661 kilobytes reserved for system use. >> 2247112876 kilobytes are available for use. >> Filesystem is dirty. >> **** Filesystem was modified. **** >> processing terminated: 7/19/2012 2:30:27 with return code: 0 exit code: 4. >> /sbin/jfs_fsck died with exit status 4 >> >> Thu Jul 19 02:30:54 2012 >> ---------------- >> >> Thanks, >> Tim >> >> On Jul 18, 2012, at 4:11 PM, Dave Kleikamp <[email protected]> wrote: >> >>> On 07/18/2012 05:43 PM, Tim Nufire wrote: >>>> Sorry, I sent the wrong jfs_fsck output in my last email.. That was for >>>> the READ-ONLY pass I did *before* trying to make repairs. The output from >>>> the read-only check is interesting because it shows the Disk Allocation >>>> Maps errors which don't get reported in the read-write repair. >>> >>> When run in read-write mode, jfs_fsck rebuilds the allocation maps from >>> scratch, so it will never report problems in them. Of course, in >>> read-only mode, it does check them for errors. >>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> Jfs-discussion mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/jfs-discussion >> > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Jfs-discussion mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/jfs-discussion ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Jfs-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jfs-discussion
