OS2 World Community Forum
OS/2, eCS & ArcaOS - Technical => Storage => Topic started 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
-
(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?
-
(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.
-
(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
-
.....
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.
-
.....
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 !)
-
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.
-
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:
-
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.
-
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
-
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.
-
Any idea about this hung / TRAP000E ?
Just a WAG, but try turning off Lazy Write (cachejfs /LW:OFF at a command prompt.).
-
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 ?
-
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
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.
-
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
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.
-
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
-
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.
-
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,
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.
-
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...
-
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):
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,
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):
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