Discussion:
HPFS386 cache problem?
(too old to reply)
Dariusz Piatkowski
2011-10-04 03:22:11 UTC
Permalink
Guys,

A very strange issue here, that I think I finally tracked down, but I just don't
understand it.

I have a MCP2 FP6 system, SMP, using HPFS386. I've got 8 HPFS partitions on 2
separate disks, all either 60 or 64Gig in size, cache is set to 128Mbyte, only
enabled for the 4 'primary' partitions, since the remaining 4 (2nd physical
disk) are nightly hot-backups. Both disks are SATA drives.

The HPFS386 specific stuff is as follows:

53.47
3-23-04 10:17a 259689 0 hpfs386.ifs

53.43
9-30-03 6:11p 27237 405 CACHE386.EXE
9-30-03 6:11p 6845 404 HPFS386.DLL
9-30-03 6:11p 348965 403 NETAPI.DLL
9-30-03 6:11p 63766 417 NETAPI32.DLL
9-30-03 6:11p 6586 405 NETSPOOL.DLL

...so basically IP_8532 level for most of it with the exception of HPFS386.IFS
being IP08608.

OK, so here is the problem, the last partition on each disk exhibits what I can
only call a 55 sec delay in saving a file.

So...as I open up one of my camera pics in PMView, re-size it, etc and attemp to
save to my last partition on a drive, the clock icon comes up...and sits there
for EXACTLY 55 secs...then if completes the save and PMView becomes responsive.
I tested this operation across all my partitions which is how I narrowed it down
to the problem being each last partition on the physical disk.

I had this same issue with Tame just last week...I moved the 'working directory'
to another spot, which of course worked out fine. But it didnt' dawn on me until
tonight when I was attempting to troubleshoot my PMView issue that it really was
one and the same thing. Tame would actually just HANG there while it attempted
to save the file once scanimage completed.

So...the question is: have any of you guys seen this? Is this related to a known
(maybe?) HPFS386 bug?

Thanks as always!
Marcel Müller
2011-10-06 07:52:49 UTC
Permalink
Hi,
Post by Dariusz Piatkowski
OK, so here is the problem, the last partition on each disk exhibits what I can
only call a 55 sec delay in saving a file.
So...as I open up one of my camera pics in PMView, re-size it, etc and attemp to
save to my last partition on a drive, the clock icon comes up...and sits there
for EXACTLY 55 secs...then if completes the save and PMView becomes responsive.
I tested this operation across all my partitions which is how I narrowed it down
to the problem being each last partition on the physical disk.
is any I/O blocked meanwhile or only one partition or only the single
application thread? What about the CPU load during delay? What about the
I/O load, does the HDD LED flash?
Post by Dariusz Piatkowski
I had this same issue with Tame just last week...I moved the 'working directory'
to another spot, which of course worked out fine. But it didnt' dawn on me until
tonight when I was attempting to troubleshoot my PMView issue that it really was
one and the same thing. Tame would actually just HANG there while it attempted
to save the file once scanimage completed.
So...the question is: have any of you guys seen this? Is this related to a known
(maybe?) HPFS386 bug?
I never heard of something like that with HFPF386. Normally it is rock
solid. But you are pretty much at the limits. 64 GB each drive, 120MB
cache is really hard for the good old driver. Probably HPFS386 is not
that well tested under this conditions.

You should consider JFS. It is out of teething troubles and often faster
too. I use it for almost ten years.
In the past I had similar problems with JFS when extracting archives
with several million small files flooding the transaction log, but never
with a single write.

However, first you should check wether you have a hanging I/O request.
If so, then HPFS is not the origin. Typically such delays correspond to
unreadable blocks. But with two disks, who knows?


Marcel
Dariusz Piatkowski
2011-10-09 14:34:51 UTC
Permalink
Dariusz Piatkowski
2011-12-20 18:59:44 UTC
Permalink
Loading...