Author Topic: WCD broken when running against JFS???  (Read 18991 times)

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: WCD broken when running against JFS???
« Reply #15 on: August 21, 2018, 04:45:21 am »
Andy: Thank you, that proves it is not a JFS issue, must be something else on my end.

Dave: I did that several times as I completed my xfer from HPFS386 to JFS, but no problem, I'll give this a whirl. What is the best JFS option for a comprehensive scan? I'm thinking something along the lines of the /F:3 maybe, although that on it's own can create problems if indadvertent files become recovered (at least in the HPFS world it could have).

Here is a little snippet from a JFS CHKDSK article that Lewis once published on his blog, I recently came across it and saved for reference in my 'JFS Library':

Code: [Select]
Check FS content
 
  Usage: chkdsk drive: [/A] [/B] [/C] [/D] [/F[:n]] [/O] [/P] [/V]
 
    /A      Enable autocheck mode (undocumented)
    /B      Perform LVM Bad Block List utility processing only
    /C      Process ifdirty after logredo
    /D      Enable debug mode (undocumented)
            all log messages written to stdout in english
    /F[:n]  Full check
            0 => read only (default)
            1 => prompt for permission for each repair
            2 => preen (default if n omitted)
            3 => Assume permission given for all repairs.
                 If exiting with clean file system, invoke LVM Bad Block
                 List utility processing on the way out.
            Note: :1 and :2 are converted to :3
    /O      Omit logredo (undocumented)
    /P      Enable pmchkdsk mode (undocumented)
    /V      Verbose messaging (ignored)
 
  Both / and - prefix supported
  Options are case-insenitive
 
  Called as
 
    chkdsk drive: /F /A [/C]
 
  for autocheck

guzzi: I'm afraid that you may be onto something as previously - truth be told - I have not paid much attention to the codepage issue. Deploying JFS it was required that 'DEVICE=G:\OS2\BOOT\UNICODE.SYS' be located BEFORE the JFS.IFS statement in CONFIG.SYS (which it is), but I really do not understand the bigger JFS implications.

I have the following further on in the CONFIG.SYS:
CODEPAGE=850,852
...but beyond that, my know-how ends.

The previous definition (which I changed at some point in time to pull in some of the Polish characters) was:
CODEPAGE=437,850
...so maybe that is it?

As a quick test (along with Dave's recommended JFS CHKDSK) I will revert back to that setup to try it out.


Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: WCD broken when running against JFS???
« Reply #16 on: August 21, 2018, 04:51:47 am »
RE: CHKDSK check, here is what I ran against my HOT-COPY parition (the nightly backup of my OS/2 boot partition):

Code: [Select]
[G:\]chkdsk i: /f:3
The current hard disk drive is: I:
The type of file system for the disk is JFS.
The JFS file system program has been started.
CHKDSK  Block size in bytes:  4096
CHKDSK  File system size in blocks:  61032935
CHKDSK *Phase 0 - Replay Journal Log
CHKDSK *Phase 1 - Check Blocks, Files/Directories, and Directory Entries
CHKDSK *Phase 2 - Count Links
CHKDSK *Phase 3 - Rescan for Duplicate Blocks and Verify Directory Tree
CHKDSK *Phase 4 - Report Problems
CHKDSK *Phase 5 - Check Connectivity
CHKDSK *Phase 7 - Rebuild File/Directory Allocation Maps
CHKDSK *Phase 8 - Rebuild Disk Allocation Maps
244131740 kilobytes total disk space.
    44916 kilobytes are in 17624 directories.
 62677223 kilobytes are in 286118 user files.
   268760 kilobytes are in extended attributes.
   161929 kilobytes are reserved for system use.
181068744 kilobytes are available for use.
CHKDSK  File system is clean.
CHKDSK  THE FILE SYSTEM IS NOW AVAILABLE.
CHKDSK  Transferring entries from the LVM Bad Block Table for this file
system to the JFS Bad Block Table for this file system.

CHKDSK  LVM reports 0 bad blocks.  Of these, 0 have been transferred
to the JFS Bad Block List.
    ..@......

Re-running the WCD scan against that single drive only (I:\) still produced the same symptom...I killed the process before it consumed all the ram.

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: WCD broken when running against JFS???
« Reply #17 on: August 26, 2018, 02:44:44 am »
OK, figured it out...problem entirely on my side and caused by my lack of understanding of the JFS configuration and it's pre-requisites.

Sooo...I moved from an all HPFS386 configuration to all JFS. To accomplish this I relied on a maintenance partition (where I executed the XCOPY from), which was configured by default to run HPFS/HPFS386 and to which I added (key point here: MANUALLY) the JFS capability.

Well, if you've done some JFS work by now you might be screaming at me: "HEY, SHMUCK, YOU FORGOT ABOUT \LANGUAGE\* DIRECTORY!". Yup, that's what it was.

The presence of the DEVICE=G:\OS2\BOOT\UNICODE.SYS statement before the JFS driver in CONFIG.SYS is a requirement to running JFS. Well, since I manually retrofitted JFS to my maint partition I had also included this statement, however what I did NOT do was to move the \LANGUAGE directory tree over. This meant that UNICODE.SYS was loading but showing some warning messages...which in hindsight I should have investigated further. In reality UNICODE.SYS was not actually loading successfully at all, in fact the reference to "\landugage\codepage" is actually hard-coded in the driver itself and since that whole directory tree was missing from my maint partition there was an impact to JFS operation.

However, since I was able to format JFS, execute XCOPY, run CHKDSK and in general use JFS just fine I had assumed that all was good. And so this is how I copied my HPFS386 based stuff to the JFS system.

Now given guzzi's hint I went back to review all this further and learn a thing or two about UNICODE.SYS and OS/2 CODEPAGE functionality. I re-formatted a test partition and having moved the \LANGUAGE tree over to my maint partition I did the full XCOPY of my OS/2 drive. Once up and running I ran WCD against it...and...SUCCESS!!!

I repeated this process on my main partition (SSD drive) and so far I'm all good. Now, does this mean I may have lost some type of information in my previous XCOPY from the HPFS386 system??? I do not know...CHKDSK always reported matching file and directory counts, although EA numbers were somewhat different.


xynixme

  • Guest
Re: WCD broken when running against JFS???
« Reply #18 on: August 12, 2019, 09:58:04 am »
I used to run WCD (RPM)

I figured I would re-do the WCD scan and get it down to just my single JFS partition...lo and behold, the 'WCD -S g:\' CLI causes one of my CPU cores to immediately spike to 100% use

Mildly off-topic: while combining and un-Unixifying 2 ZIP packages of WCD, mainly by removing all useless subdirectories and MAN files, I noticed that WCD should support an undocumented %WCDHOME% environment variable. Since %HOME% is hardly worth a full backup, users could consider to set this variable and save the tree (and other WCD files) in some more important directory, e.g. WCD's single own directory.

I haven't tested this yet, because WCD's first unexpected result was building a directory tree of the current %HOME% setting.