JFS TRAP000E during unzip on JFS partition (same unzip on fat32 is ok)

[Remy]

Stat output:

  Fichier : w:
   Taille : 0            Blocs : 8          Blocs d'E/S : 49152  répertoire
Périphérique : 5657h/22103d   Inud : 8778591906650128431  Liens : 1
Accès : (0777/drwxrwxrwx)  UID : (    0/    root)   GID : (    0/    root)
 Accès : 2022-02-04 01:06:26.000000000 +0100
Modif. : 2022-12-11 15:59:12.000000000 +0100
Changt : 2022-12-11 15:59:12.000000000 +0100
  Créé : 2022-02-04 01:06:26.000000000 +0100

[Remy]

Found: DFSEE provides partition info too.
Fileset1 IAGs  30 :   71680 Inodes, used :   69599   MaxInodeNumber : 0x0001dfff
AggregateIAGs   1 :      32 Inodes, used :       6   MaxInodeNumber : 0x00000fff

Inodes are below max number x'1dfff' or 122879

chkdsk from boot DVD provided a ok fs.
I just run JFS check from under DFSEE :

....
0x029427F8 none            0x00000180 =   192.0 KiB Unidentified data  00000002
       - Allocation set but area not in FS-administration
0x02942A80 none            0x00000100 =   128.0 KiB Unidentified data  00000002
       - Allocation set but area not in FS-administration
0x02942C40 none            0x00000140 =   160.0 KiB Unidentified data  00000002
       - Allocation set but area not in FS-administration
0x029480A0 none            0x000000C0 =    96.0 KiB Unidentified data  00000002
       - Allocation set but area not in FS-administration
0x029481D0 none            0x000000C0 =    96.0 KiB Unidentified data  00000002
       - Allocation set but area not in FS-administration
0x029482C0 none            0x00000200 =   256.0 KiB Unidentified data  00000002
       - Allocation set but area not in FS-administration
0x02948500 none            0x00000400 =   512.0 KiB Unidentified data  00000002
       - Allocation set but area not in FS-administration
0x02948A80 none            0x00000240 =   288.0 KiB Unidentified data  00000002
       - Allocation set but area not in FS-administration
0x02948EC0 none            0x00000140 =   160.0 KiB Unidentified data  00000002
       - Allocation set but area not in FS-administration
0x0294E180 none            0x00000080 =    64.0 KiB Unidentified data  00000002
       - Allocation set but area not in FS-administration
0x0294E2A8 none            0x00000040 =    32.0 KiB Unidentified data  00000002
       - Allocation set but area not in FS-administration
0x0294EA80 none            0x00000180 =   192.0 KiB Unidentified data  00000002
       - Allocation set but area not in FS-administration
0x0ACA7570 none            0x00000280 =   320.0 KiB Unidentified data  00000002
       - Allocation set but area not in FS-administration

Total errors/warnings detected:   19
Areas allocated but not linked:   18, size 0x00001640 =  2848.0 KiB

ReadWrite Store A : PhysDisk : 3 PartId 05 = W:   mode=JFS       20221212-123944  SLT: 1
RC:19    = 0x13   : 0x00000000   up=0x00000059  this=0x00000000  Base=0x0440A01B  Xtra=0

It looks like something is wrong seen by dfsee but not chkdsk.
 

[Dave Yeo]

Forgot about DFsee, those errors are likely your problem. You could try running chkdsk /D on the volume, probably won't help but who knows. Ideally would to back up and reformat, ideally a long format to check for bad blocks.
As for inodes, if they were fixed and you ran out, you should simply get a disk full error. Further reading from the developers, https://jfs.sourceforge.net/project/pub/jfs.pdf gives,

Dynamic disk inode allocation
JFS dynamically allocates space for disk inodes as required, freeing the space when it is no longer
required. This support avoids the traditional approach of reserving a fixed amount of space for disk
inodes at the file system creation time, thus eliminating the need for users to estimate the maximum
number of files and directories that a file system will contain. Additionally, this support decouples
disk inodes from fixed disk locations.

[Remy]

I run different chkdsk and could see one time errors in the journalized file !
I had to scratch a spare disk and lost some files I had for backup, create a partion on it and then, I did a xcopy of all files from the suspected partition to this "new temporary partition for this issue".
I could format JFS the partition having issue in the JFS journal (invalid pointers)
Run chkdsk on it and it seems ok.
Then, I copied back (xcopy) all files from my temp partition to this working partition having the @unixroot
Reboot and could copy several more files on it without errors (better)
Now, I'm going to test with the copy of bigger files and check result...

[Dariusz Piatkowski]

Remy,

Here are the JFS chkdsk specific notes I saved at some point in time (sorry, don't remember where I got these, although I want to say most likely off of the AOS Testers' list):

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


[Remy]

Remy,

Here are the JFS chkdsk specific notes I saved at some point in time (sorry, don't remember where I got these, although I want to say most likely off of the AOS Testers' list):

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


Thanks Dariusz,

Yes, More interesting where /D and /F:3
I could see that invalid pointers exists but could not be corrected.

The format resolved the issue and now, I'm able to copy more and more files again, well above the limit where trap occured.
A trap is not a solution and I think that invalid pointer should be handled and write error should be issued to stop current processing instead of trap resulting into a power off/on to recover.

Thanks