OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Storage => Topic started by: Remy on December 04, 2022, 12:58:25 am

Title: JFS TRAP000E during unzip on JFS partition (same unzip on fat32 is ok)
Post by: Remy on December 04, 2022, 12:58:25 am
Hi !

I could unzip a zip archive file with 12 DSF64 files in it on a JFS partition.
I then tried to unzip on other one with less files in it but all are big files (between 450MB and 800MB each)
It start the unzip and than a system hung or a trap000E.
I tried it several time and always got the same result (first, a system hung and after a reboot, new try -> trap000E)
I than tried to unzip a single file but I've got the same result.
At least, I tried a unzip of this archive file selecting all files into a FAT32 partition and it ended successful !
.
Any idea about this hung / TRAP000E ?
(latest ArcaOS release + all modules at latest level)

Regards
Rémy
Title: Re: JFS TRAP000E during unzip on JFS partition (same unzip on fat32 is ok)
Post by: Andi B. on December 04, 2022, 12:28:29 pm
Quote
(latest ArcaOS release + all modules at latest level)
New clean ArcaOS installation? Then it's best to open a ticket at AN.

I ask this cause I think you're the one with the DVD/JFS/UNICODE ticket we discussed the last days and in this ticket it turned out that you didn't test on a fresh ArcaOS installation but installed these faulty cputemp package which in turn leads to your trap you reported there. That said I fear no one here can guess what your page fault (000E) really triggered. Your memory settings or?
Title: Re: JFS TRAP000E during unzip on JFS partition (same unzip on fat32 is ok)
Post by: Remy on December 04, 2022, 05:33:24 pm
Quote
(latest ArcaOS release + all modules at latest level)
New clean ArcaOS installation? Then it's best to open a ticket at AN.

I ask this cause I think you're the one with the DVD/JFS/UNICODE ticket we discussed the last days and in this ticket it turned out that you didn't test on a fresh ArcaOS installation but installed these faulty cputemp package which in turn leads to your trap you reported there. That said I fear no one here can guess what your page fault (000E) really triggered. Your memory settings or?

It looks there is confusion.
It isn't me.
Title: Re: JFS TRAP000E during unzip on JFS partition (same unzip on fat32 is ok)
Post by: Remy on December 04, 2022, 05:42:22 pm
Quote
(latest ArcaOS release + all modules at latest level)
New clean ArcaOS installation? Then it's best to open a ticket at AN.

I ask this cause I think you're the one with the DVD/JFS/UNICODE ticket we discussed the last days and in this ticket it turned out that you didn't test on a fresh ArcaOS installation but installed these faulty cputemp package which in turn leads to your trap you reported there. That said I fear no one here can guess what your page fault (000E) really triggered. Your memory settings or?

I'm under ArcaOS 5.0.7 since a long time now.

What I reported under the post where someone got a trap due installed cputemp package due missing unicode is that I had in the past when i was under v5.0.2 ArcaOS a similar JFS issue after having installed Lotus french package creating path names with accent characters.

This is completly different, no unicode, no accent chars problem, no pathname issue.
It start writting for a few seconds before getting the trap.
Ticket opened
Title: Re: JFS TRAP000E during unzip on JFS partition (same unzip on fat32 is ok)
Post by: Andi B. on December 04, 2022, 07:17:25 pm
.....

It looks there is confusion.
It isn't me.
I didn't know there are more than one Remy using ArcaOS. This ticket I posted in the other threat is what I meant - https://mantis.arcanoae.com/view.php?id=1223. Out of curiosity this was a TRAP 000E too.
Title: Re: JFS TRAP000E during unzip on JFS partition (same unzip on fat32 is ok)
Post by: Remy on December 04, 2022, 09:41:57 pm
.....

It looks there is confusion.
It isn't me.
I didn't know there are more than one Remy using ArcaOS. This ticket I posted in the other threat is what I meant - https://mantis.arcanoae.com/view.php?id=1223. Out of curiosity this was a TRAP 000E too.

Oh ! I apology, yes, right it was me but a very old case from 2017 resolved in 2017 (older ArcaOs release)
Now and I'm under ArcaOS 5.0.7  (after check, I have rdmsr.sys - May be I put it back after 5.0.7 migration - I just added a Warning REM line into my config.sys about this driver)   

I don't think this driver has something to do here due following test:
About the new issue, could it be possible I exceed authorized number of files or dirs on this partition ? or may be exceed possible JFS entries ?
(Deleted about 20 files and the copy could be done without trap !)
Title: Re: JFS TRAP000E during unzip on JFS partition (same unzip on fat32 is ok)
Post by: Lars on December 05, 2022, 01:20:01 pm
It would be interesting if that Trap E always occurs at the very same location (the lowest 4 hex digits of EIP having the same value would be a good indication, I don't have access to ticket 1223).

The trap is due to an attempt to write data to a non-present page. Taking the value displayed for CR2, I would think a NULL pointer being accessed (with an offset of 0x38). It's difficult to say what would have caused that but a NULL pointer check should be added in JFS.IFS.
Since JFS.IFS dynamically allocates memory from an internal pool whenever that is necessary, maybe all memory was depleted and a NULL pointer returned. Since it seems to depend on file size, it may have something to do with allocating "inode" management data.
Title: Re: JFS TRAP000E during unzip on JFS partition (same unzip on fat32 is ok)
Post by: Remy on December 05, 2022, 02:38:12 pm
It would be interesting if that Trap E always occurs at the very same location (the lowest 4 hex digits of EIP having the same value would be a good indication, I don't have access to ticket 1223).

The trap is due to an attempt to write data to a non-present page. Taking the value displayed for CR2, I would think a NULL pointer being accessed (with an offset of 0x38). It's difficult to say what would have caused that but a NULL pointer check should be added in JFS.IFS.
Since JFS.IFS dynamically allocates memory from an internal pool whenever that is necessary, maybe all memory was depleted and a NULL pointer returned. Since it seems to depend on file size, it may have something to do with allocating "inode" management data.

Ticket number for this issue:
https://mantis.arcanoae.com/view.php?id=3366

chkdsk of the partition run from ArcaOs boot DVD:
Title: Re: JFS TRAP000E during unzip on JFS partition (same unzip on fat32 is ok)
Post by: Dariusz Piatkowski on December 05, 2022, 02:51:44 pm
Hi Remy!

I'm curious if by any chance you hit the same issue I did back in Jan of this year, see this thread => 'JFS - Trap 0003 - anyone?' (https://www.os2world.com/forum/index.php/topic,2962.0.html (https://www.os2world.com/forum/index.php/topic,2962.0.html))

Specifically for me this was caused by the JFS cache size (and the MIN & MAX buffer parameters) and the size of the file I was working on. It was reproducible as well.
Title: Re: JFS TRAP000E during unzip on JFS partition (same unzip on fat32 is ok)
Post by: Remy on December 05, 2022, 03:53:36 pm
Hi Remy!

I'm curious if by any chance you hit the same issue I did back in Jan of this year, see this thread => 'JFS - Trap 0003 - anyone?' (https://www.os2world.com/forum/index.php/topic,2962.0.html (https://www.os2world.com/forum/index.php/topic,2962.0.html))

Specifically for me this was caused by the JFS cache size (and the MIN & MAX buffer parameters) and the size of the file I was working on. It was reproducible as well.

Same location.
Interesting, I use default AN size
What are you cache / buffer sizes ?

Of course, trap should not occur and warning messages should be issued several seconds before any other deeper issue followed by may be a kill of the process which could put the system into a trap situation...  ::)   

Regards
Title: Re: JFS TRAP000E during unzip on JFS partition (same unzip on fat32 is ok)
Post by: Dariusz Piatkowski on December 05, 2022, 04:52:09 pm
Same location.
Interesting, I use default AN size
What are you cache / buffer sizes ?

I have a bit of a different setup here, that being:

- CACHE = 1G
- MIN_BUFFER = 8000
- MAX_BUFFER = 16000

- SYNC_TIME = 32
- MAX_AGE = 128
- BUFFER_IDLE = 8

My machine is powered by a UPS, so unless something catastrophic actually happens I can afford the long sync time and max age setups. The machine uses SSDs here (Samsung 850 & 860 Evo) but still limitted by the SATA3 interface, so FS cache certainly helps.

From a personal 'interested in this stuff' perspective I have been testing different MIN & MAX buffer configs and found this 8k<=>16K to be a sweet spot for my use. Basically, regular 15-20 day uptimes of standard heavy web use, email, and occasional DEV work with a good balance of JFS's nfreecbufs and slrun<slruN while attempting to keep jbufs_protected as high as I can.
Title: Re: JFS TRAP000E during unzip on JFS partition (same unzip on fat32 is ok)
Post by: Doug Bissett on December 06, 2022, 11:26:50 pm
Quote
Any idea about this hung / TRAP000E ?

Just a WAG, but try turning off Lazy Write (cachejfs /LW:OFF at a command prompt.).
Title: Re: JFS TRAP000E during unzip on JFS partition (same unzip on fat32 is ok)
Post by: Remy on December 12, 2022, 02:08:12 am
Changing cache size or whatelse didn't prevent the trap except deleting files...

I could read that JFS has a fixed number of i-nodes
May it be possible i reached this maximum value ?
How to check i-nodes ?
Title: Re: JFS TRAP000E during unzip on JFS partition (same unzip on fat32 is ok)
Post by: Dave Yeo on December 12, 2022, 03:07:31 am
Hi Remy, I think you are confusing JFS with JFS2. JFS was AIX's file system and had a fixed number of inodes. JFS2 was a rewrite of JFS, first for OS/2, then ported to Linux and AIX and has a dynamic number of inodes.
You can use the stat command or ls -i
Code: [Select]
H:\>stat h:/
  File: h:/
  Size: 0               Blocks: 0          IO Block: 49152  directory
Device: 5648h/22088d    Inode: 8778591906650128431  Links: 1
Access: (0777/drwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2022-12-11 21:56:36.000000000 -0800
Modify: 2022-12-11 17:07:30.000000000 -0800
Change: 2022-12-11 17:07:30.000000000 -0800
 Birth: 2022-12-11 21:56:36.000000000 -0800

H:\>ls -i h:/
9872134062851590269 jfs.part  1282181188518208385 mozilla
3386936443230352367 mm         773427466165056712 tmp

H:\>stat k:/
  File: k:/
  Size: 0               Blocks: 8          IO Block: 49152  directory
Device: 564bh/22091d    Inode: 8778591906650128431  Links: 1
Access: (0777/drwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2022-04-05 04:02:40.000000000 -0700
Modify: 2022-11-19 21:23:18.000000000 -0800
Change: 2022-11-19 21:23:18.000000000 -0800
 Birth: 2021-08-11 18:48:36.000000000 -0700

H: is my 12GB JFS ram disk, K: is 300GB JFS partition. I'm not totally sure that these commands work correctly on OS/2. Need to test on Linux
I've used enough inodes, lots of small files, that chkdsk would fail due to OOM (out of memory), no crash.
Title: Re: JFS TRAP000E during unzip on JFS partition (same unzip on fat32 is ok)
Post by: Remy on December 12, 2022, 10:03:05 am
Hi Remy, I think you are confusing JFS with JFS2. JFS was AIX's file system and had a fixed number of inodes. JFS2 was a rewrite of JFS, first for OS/2, then ported to Linux and AIX and has a dynamic number of inodes.
You can use the stat command or ls -i
Code: [Select]
H:\>stat h:/
  File: h:/
  Size: 0               Blocks: 0          IO Block: 49152  directory
Device: 5648h/22088d    Inode: 8778591906650128431  Links: 1
Access: (0777/drwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2022-12-11 21:56:36.000000000 -0800
Modify: 2022-12-11 17:07:30.000000000 -0800
Change: 2022-12-11 17:07:30.000000000 -0800
 Birth: 2022-12-11 21:56:36.000000000 -0800

H:\>ls -i h:/
9872134062851590269 jfs.part  1282181188518208385 mozilla
3386936443230352367 mm         773427466165056712 tmp

H:\>stat k:/
  File: k:/
  Size: 0               Blocks: 8          IO Block: 49152  directory
Device: 564bh/22091d    Inode: 8778591906650128431  Links: 1
Access: (0777/drwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2022-04-05 04:02:40.000000000 -0700
Modify: 2022-11-19 21:23:18.000000000 -0800
Change: 2022-11-19 21:23:18.000000000 -0800
 Birth: 2021-08-11 18:48:36.000000000 -0700

H: is my 12GB JFS ram disk, K: is 300GB JFS partition. I'm not totally sure that these commands work correctly on OS/2. Need to test on Linux
I've used enough inodes, lots of small files, that chkdsk would fail due to OOM (out of memory), no crash.

Thanks Dave, I'll check results on my side

Note:
I read under ecomstation that i-nodes have a fixed number set at initial time and if exausted, no more files can be writren despite frees space under the partition exist.
Title: Re: JFS TRAP000E during unzip on JFS partition (same unzip on fat32 is ok)
Post by: Remy on December 12, 2022, 12:21:18 pm
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
Title: Re: JFS TRAP000E during unzip on JFS partition (same unzip on fat32 is ok)
Post by: Remy on December 12, 2022, 12:38:24 pm
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.
 
Title: Re: JFS TRAP000E during unzip on JFS partition (same unzip on fat32 is ok)
Post by: Dave Yeo on December 12, 2022, 06:24:48 pm
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 (https://jfs.sourceforge.net/project/pub/jfs.pdf) gives,
Quote
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.
Title: Re: JFS TRAP000E during unzip on JFS partition (same unzip on fat32 is ok)
Post by: Remy on December 12, 2022, 06:46:57 pm
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...
Title: Re: JFS TRAP000E during unzip on JFS partition (same unzip on fat32 is ok)
Post by: Dariusz Piatkowski on December 13, 2022, 02:29:06 am
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
Title: Re: JFS TRAP000E during unzip on JFS partition (same unzip on fat32 is ok)
Post by: Remy on December 13, 2022, 05:22:45 pm
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