Hi Everyone,
Umm...something strange happened to me this morning: I was editting my RSYNC LOG file so I could archive the 2022 stuff and start new for 2023. Needless to say, the file is about 25M in size...so plain vanilla editor just takes a little extra time.
I had done this with the good ol' trusty E.exe before, but I figured I would give AE a try (v1.9.x). Editing went fine, no faster than E.exe, however once edited EA hung trying to save it back to the disk. I waited, and waited, following which I tried to kil EA, no go though. Rolled out the full gamut of kill options, still no go.
Ultimately I selected the Reboot option from CAD-Popup as EA was literally blocking WPS (nothing else worked), but even than hung. So as a final attempt to recover I did CTL-ALT-NUMLCK x2, which put me in the dump screen, and then I reset.
Now, in the past, that desparate attempt to recover has always worked. It also has NEVER caused me a JFS issue, however this time...man...upon reboot the JFS CHKDSK went to work full-time...pile of stuff scrolled by (too fast of course to see any of it) and machine came back up. INIs were corrupted, no problem, I have regular backups, so a couple of reboots later I was back up and running.
However, not liking that longish list of CHKDSK results I went fishing to learn more about it.
As it happens I have the following in my STARTUP.CMD:
...
chklgjfs g: >> g:\tmp\log\chklgjfs-g.log
...
which is done for ALL the drives.
In my case, this produced the following:
____________________________________________________________________
chkdsk service log selected: MOST RECENT
XCHKLOG P superblock is valid.
**********************************************************
CHKDSK processing started: 1/14/2310.56.1
CHKDSK parameter detected: AutoCheck mode
CHKDSK parameter detected: IfDirty
CHKDSK The current hard disk drive is: g:
CHKDSK DosOpen(...OPEN_SHARE_DENYREADWRITE|OPEN_ACCESS_READWRITE...) returned rc = 0
CHKDSK DosDevIOCtl(...DSK_GETDEVICEPARAMS...) returned rc = 0
CHKDSK Primary superblock is valid.
CHKDSK The type of file system for the disk is JFS.
CHKDSK The boot sector has been refreshed.
CHKDSK Filesystem is clean.
CHKDSK All observed inconsistencies have been repaired.
CHKDSK Filesystem has been marked clean.
CHKDSK **** Filesystem was modified. ****
CHKDSK LVM GetBadBlockInformation returned rc = 22
CHKDSK processing terminated: 1/14/2310.56.1 with return code: 0.
____________________________________________________________________
The problem here is that this doesn't tell me anything about WHAT actually was detected and what JFS did to attempt to correct it.
Sure enough...as I attempted to fire up a few of my regular apps like PMMail for example, I came to discover that those directories have missing files, etc.
So clearly there is a JFS problem here, and as opposed to HPFS where the HPFS CHKDSK log viewer would at least clearly show the objects that were impacted, it would appear that JFS has no such functionality.
How can that be though? I must be missing something...
So how are you guys getting visibility into what JFS CHKDSK log has found and/or corrected?
BTW: Nothing in \lost+found directory, so no actual directories or files were recovered...