OS/2, eCS & ArcaOS - Technical > Utilities

WCD broken when running against JFS???

(1/4) > >>

Dariusz Piatkowski:
Ugghhh????!!!  :o

Yeah...strange right?

So I am literally coming out of a move from my multi-HPFS386-partition setup to a much simpler and (hopefully) more efficient JFS partition setup.

Since all HPFS partitions are limitted to 64Gig it was just getting to be too painfull watching the system boot, let alone the occasional CHKDSK execute here and there. In combination I also deployed a SSD drive (Samsung Evo850 - 250Gig) to replace my aging WD Raptor (BTW: if you have not thought about it...I am telling you, there is no computing like "SSD Computing" LOL...that sweet!!!).

Anyways, so I managed to get the partitions migrated (xcopy, sysinstx, etc), all came up fine. I replaced multiple HPFS386 partitions with a single JFS boot partition. So I went from multiple 64Gig to a single 233Gig drive.

Now here is where it gets weird. I used to run WCD (RPM 6.0.2, 2018-05-10 drop) very successfully in the past. Since I got rid of a pile of HPFS386 partitions I figured I would re-do the WCD scan and get it down to just my single JFS partition...lo and behold, the 'WCD -S g:\' CLI causes one of my CPU cores to immediately spike to 100% use, RAM to be consumed (pretty fast too) and eventually producing a trap:


--- Code: ---[G:\usr\bin]wcdos2 -S g:\
Wcd: Please wait. Scanning disk. Building treedata-file g:/home/wcd/treedata.wcd
 from g:/

Killed by SIGSEGV
pid=0x0068 ppid=0x0065 tid=0x0001 slot=0x00e2 pri=0x0200 mc=0x0001 ps=0x0010
G:\USR\BIN\WCDOS2.EXE
LIBC066 0:0004cecb
cs:eip=005b:1d6dcecb      ss:esp=0053:00139d94      ebp=0013a058
 ds=0053      es=0053      fs=150b      gs=0000     efl=00010212
eax=00000000 ebx=ab030000 ecx=ab030000 edx=2003013c edi=00000009 esi=00139ecd
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

--- End code ---

Before I log a ticket (because this is really weird, I have never seen anything like this before), has anyone experienced this?

Pete:
Hi Dariusz

I must admit to never having used wcd myself but the trap looks libc066 related. Is your "unix system" up to date with no older copies hanging around?

I note that you have "... replaced multiple HPFS386 partitions with a single JFS boot partition." which I do not think is a good idea. My own experience of JFS boot volumes is that they can be somewhat unreliable - and somewhere on the Arca website HPFS rather than JFS is recommended for boot volumes. My own preference is to use small (2Gb is more than adequate) HPFS boot volumes and have apps/data on larger JFS volumes. Just my thoughts...


Regards

Pete




Doug Bissett:
I agree that boot volumes should be small (about 2 GB, is more than adequate), and programs/data should be on a different drive. I do NOT agree that the boot volumes should be HPFS. I find that JFS works remarkably well for boot drives. Far better than HPFS ever did (especially when a boot time CHKDSK is required, which is almost "never"). The only thing that I use HPFS for is the RAMDISK (only because it is more difficult to convert it to JFS, and I can make the HPFS cache very small to minimize the adverse effect of using a cache with a RAMDISK).

As for WCD, I haven't used it, so I really can't comment. If Peter's suggestion that the problem is LIBC related, the latest version seems to have fixed a number of problems.

Somebody, somewhere, also suggested adding the line:

--- Code: ---SET LIBCX_HIGHMEM=2
--- End code ---
to CONFIG.SYS. As Peter said, make sure that you don't have stray copies of the RPM/YUM stuff laying around. Give them half a chance, and they will cause problems.

Andy Willis:
I've never used wcd either, I had built a REXX changdir years ago and then once I started using 4os2 I largely use the built in cdd.  Any how, I downloaded the WCD 5.3.0 builds from hobbes.
The only reason I have HPFS at this point is like Doug, my RAMDISK is HPFS, in my case because I don't know any way to format it JFS when I have my swapper.dat on it.  I couldn't set the /cache for HPFS less than 8 (otherwise it defaults to 64) but in startup.cmd I turn off the hpfs lazy and readahead cache. 
I do not have the sigsegv in wcdos2.  However, I do see a major difference between the gcc and watcom builds in the treedata.wcd.
The gcc built wcdos2 adds the first 11 directories, then it skips some thousands of directories and then picks up e:\usr\bin and the one directory I have under e:\usr\bin.  So all in all it picks up 13 directories.  It does this very very quickly.
The watcom build wcdos2 runs much much longer and seems to pickup every directory in treedata.wcd (175598 directories listed).
All in all the gcc built version behaves quite oddly here.

Silvan Scherrer:
Which wcd build it the gcc one? The one from RPM? As imho the most current one is 6.0.2.

Navigation

[0] Message Index

[#] Next page

Go to full version