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

[Remy]

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

[Andi B.]

(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?

[Remy]

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

[Remy]

(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

[Andi B.]

.....

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.

[Remy]

.....

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 !)

[Lars]

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.

[Remy]

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:

[Dariusz Piatkowski]

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)

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.

[Remy]

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)

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

[Dariusz Piatkowski]

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.

[Doug Bissett]

Any idea about this hung / TRAP000E ?

Just a WAG, but try turning off Lazy Write (cachejfs /LW:OFF at a command prompt.).

[Remy]

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 ?

[Dave Yeo]

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.

[Remy]

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.