OS/2, eCS & ArcaOS - Technical > Storage

JFS - chkdsk LOG - where?


Dariusz Piatkowski:
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:

--- Code: ---...
chklgjfs g: >> g:\tmp\log\chklgjfs-g.log

--- End code ---

which is done for ALL the drives.

In my case, this produced the following:

--- Code: ---____________________________________________________________________
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  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.


--- End code ---

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

Dave Yeo:
Hi Dariusz,
Recently, I had a trap in JFS, so I ran chkdsk k: /F:3, it fixed a bunch of stuff including putting mostly empty directories/files in lost+found. Doing chklgjfs K: did show the fixes that were done, never saved it though.
Sounds like in your case the buffer got overrun or such. Might want to do a further chkdsk g: /f:3 on your drive.

Dariusz Piatkowski:
Hi Dave!

Yup, booted to my MAINT partition and manually ran a CHKDSK against all the JFS drives. Only one reported errors, and that was the backup of the MAINT partition, so low risk.

Given that I do nightly backups I was able to run a quick compare between the drive listings afterwards and narrow this down to about 10 different files (all over the place though, so not just a single directory).

Anyways, that allowed me to fix the issues and get my machine back up to a fully functioning status.

But man...not to have visibility to what JFS CHKDSK does is a scary feeling...why isn't it producing a CHKDSK.LOG like HPFS did? Strange since running 'chkdks drive: /p' will even show the MSG statements for each check operation and that's primarily the sort of stuff that HPFS used to log into the LOG file.


[0] Message Index

Go to full version