Author Topic: JFS chkdsk problem  (Read 1638 times)

Per E. Johannessen

  • Full Member
  • ***
  • Thank You
  • -Given: 4
  • -Receive: 0
  • Posts: 136
    • View Profile
JFS chkdsk problem
« on: July 19, 2019, 09:49:54 pm »
Have a problem with a jfs formatted partition. After a reboot (ArcoOS), chkdsk seems to be stuck in phase 3 when checking the "troubled" partition which has driveletter P. Disabled autocheck in config.sys and the system boots to the WPS, drive P still exists but the systems cannot list any files/directories. Is there any "safe" tool to fix this?

ivan

  • Hero Member
  • *****
  • Thank You
  • -Given: 2
  • -Receive: 35
  • Posts: 1018
    • View Profile
Re: JFS chkdsk problem
« Reply #1 on: July 19, 2019, 10:07:43 pm »
Assuming you have a good backup of that partition then the safest way to proceed is format the partition and restore the data.

I had that happen to me once and the 'format/restore' was the only way out.  Depending on how old the disk is and what it's highest temperature has been you might need to run the manufacturers linux based disk tools to check if there are low level problems, bad sectors, no reserve sectors left to use, etc.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 149
  • Posts: 2148
    • View Profile
Re: JFS chkdsk problem
« Reply #2 on: July 20, 2019, 01:29:09 am »
You could try chkdsk /d P:
At worst, I've recovered stuff by mounting the partition readonly on Linux. You could also try Linux's fsck.jfs.
JFS seems to have problems when the volume has little free space.

Per E. Johannessen

  • Full Member
  • ***
  • Thank You
  • -Given: 4
  • -Receive: 0
  • Posts: 136
    • View Profile
Re: JFS chkdsk problem
« Reply #3 on: July 20, 2019, 02:10:13 pm »
I have a good backup so I already recreated the partion and formatted it JFS. However, when copying files back to this new partition the title of the files remain correct but the actual file names are shortened to 8.3. When opening drive P: in details view I can edit the titles but the real name does not get updated correctly if the tilte is longer consists of more then 8 characters. (This procedure works fine on other JFS partitions,.)

Andy Willis

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 10
  • Posts: 203
    • View Profile
Re: JFS chkdsk problem
« Reply #4 on: July 20, 2019, 03:29:41 pm »
In config.sys, does the unicode.sys line precede the JFS.ifs line?

Andreas Schnellbacher

  • Sr. Member
  • ****
  • Thank You
  • -Given: 1
  • -Receive: 24
  • Posts: 437
    • View Profile
Re: JFS chkdsk problem
« Reply #5 on: July 20, 2019, 03:30:58 pm »
8.3 - that sounds like the known WPS bug. After formatting, restart the system. Then you can use the WPS to copy files. Before that, you should only use non-WPS tools (e.g. command line or file managers) to act with that volume.

Per E. Johannessen

  • Full Member
  • ***
  • Thank You
  • -Given: 4
  • -Receive: 0
  • Posts: 136
    • View Profile
Re: JFS chkdsk problem
« Reply #6 on: July 20, 2019, 04:11:26 pm »
Yes, unicode.sys precedes the JFS.ifs line.

Didn't know about that WPS bug. In the meantime I reformatted p: with HPFS and and copying files to it keep correct file names.

During all this back and forth I've ended up with some backup directories with real file names in the 8.3 format. Is there a script/utility than can be run on these directories/files which will set real name equal to title?

André Heldoorn

  • Hero Member
  • *****
  • Thank You
  • -Given: 119
  • -Receive: 19
  • Posts: 787
    • View Profile
Re: JFS chkdsk problem
« Reply #7 on: July 20, 2019, 05:32:27 pm »
Presumably such an utility is: Ren83toLONGNAME100.zip

Per E. Johannessen

  • Full Member
  • ***
  • Thank You
  • -Given: 4
  • -Receive: 0
  • Posts: 136
    • View Profile
Re: JFS chkdsk problem
« Reply #8 on: July 20, 2019, 06:40:52 pm »
Thank you, got it.

Andreas Schnellbacher

  • Sr. Member
  • ****
  • Thank You
  • -Given: 1
  • -Receive: 24
  • Posts: 437
    • View Profile
Re: JFS chkdsk problem
« Reply #9 on: July 20, 2019, 07:15:56 pm »
Didn't know about that WPS bug. In the meantime I reformatted p: with HPFS
Note that the WPS bug is not limited to any file system.

Matt Walsh

  • Newbie
  • *
  • Thank You
  • -Given: 3
  • -Receive: 1
  • Posts: 31
    • View Profile
Re: JFS chkdsk problem
« Reply #10 on: July 21, 2019, 05:53:39 pm »
As far as recovering data from a JFS partition/volume I had good luck with JRescuer by Pavel Shtemenko.  It's worth the small cost for time saved if you don't have a full current backup.
Matt W.

Lars

  • Sr. Member
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 43
  • Posts: 421
    • View Profile
Re: JFS chkdsk problem
« Reply #11 on: July 22, 2019, 11:57:39 am »
I have a good backup so I already recreated the partion and formatted it JFS. However, when copying files back to this new partition the title of the files remain correct but the actual file names are shortened to 8.3. When opening drive P: in details view I can edit the titles but the real name does not get updated correctly if the tilte is longer consists of more then 8 characters. (This procedure works fine on other JFS partitions,.)

Is this a partition on a removable drive (say USB drive or so ?). I have found that this problem happens when the drive is loaded as "non-removable" by the device manager (OS2DASD.DMD). you can tell by the look of the drive icon: if it displayed a fixed hard drive icon, then it means that it is treated as "non-removable" (which usually happens if you have attached the drive already on system start), if it displays a different icon then it is treated as "removable". If it is treated as "non-removable" you will need to eject the drive and then to have it rediscovered by LVM. After that, the problems with restricted filenames is gone and the system will fully support long filenames (as long as the underlying filesystem supports that).

Because I tend to forget to have the medium ejected on system start, I have written a WPS class that will rename the file/folder to its long filename/foldername aka. "title" (which I guess is saved in the files/folders EAs). It works for a single file, a folder including all its content or even on a whole disk by selecting this action from the file/folder/disk context menu:

http://hobbes.nmsu.edu/download/pub/os2/util/wps/filesys3.wpi

By the way: this WPS class extension peacefully (I hope ...) coexists with any other WPS class extension (XWorkplace etc.)


Lars
« Last Edit: July 22, 2019, 12:02:59 pm by Lars »

Per E. Johannessen

  • Full Member
  • ***
  • Thank You
  • -Given: 4
  • -Receive: 0
  • Posts: 136
    • View Profile
Re: JFS chkdsk problem
« Reply #12 on: July 22, 2019, 05:38:16 pm »
The partition was on a non-removable drive, internal SSD, and it's icon was identical to the other partitions on the drive.

BTW, when I first tried to manually rename the files/folders, that were copied from a backup to the newly created JFS-partition, to their original long names it did not work. After reformatting to HPFS all seems to work fine.
Thanks for the link to filesys3.wpi, I have nothing to test it on now, so I don't know if it would have worked on the partition that didn't "accept" manual editing.

Would like to go back to JFS since it's a bit faster than HPFS, but without knowing what caused the problems in the first place I'm not sure what to do. Suspect a hardware failure so perhaps just buy a new SSD drive asap, anyone knows if there is one brand that is known to be more reliable than others?

André Heldoorn

  • Hero Member
  • *****
  • Thank You
  • -Given: 119
  • -Receive: 19
  • Posts: 787
    • View Profile
Re: JFS chkdsk problem
« Reply #13 on: August 10, 2019, 10:26:28 pm »
Presumably such an utility is: Ren83toLONGNAME100.zip

FWIW: I've never used this myself, but there seems to be at least one bug. It looks like its argument can be any directory, but not a root directory. And it uses ANSI without enabling ANSI (which in "on" by default, BTW). And its execution speed can be optimized by storing less unchecked RCs, and it doesn't check all more important RCs (like the SysFileTree()-one).

FTR. No RFC, because I'm not using it, and I may think that a test run-option could be more important than replacing RCs by CALLs.

An own fix, to deal with a dropped or typed root directory, is trivial. Replace the existing lines 53, 54 and 55 of the Rexx source file by:

Code: [Select]
mdrivepath=STRIP(mdrivepath,'B','"') || '\'    /* event. " (bei dirs mit leerzeichen) müssen weg */
IF RIGHT(mdrivepath,1)<>'\' THEN mdrivepath=mdrivepath || '\'    /* event. \ dazu */
"@ANSI ON"

If you'd want to overdo it, then M.DLL offers MANSI() to replace "@ANSI ON":

Code: [Select]
CALL RxFuncAdd 'MANSI','M','MANSI'
IF MANSI('ON')='OFF' THEN SAY 'ANSI support is not available now. Please ignore displayed weird characters.'
« Last Edit: August 10, 2019, 10:34:17 pm by André Heldoorn »