From: "Dariusz Piatkowski" <dariusz@_NO-SPAM_mnsi.net>

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!




--- NewsGate v1.0 gamma 2
* Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)

From: =?ISO-8859-1?Q?Marcel_M=FCller?= <news.5.maazl@spamgourmet.com>

Hi,

On 04.10.2011 05:22, Dariusz Piatkowski wrote:
> 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?

> 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
--- NewsGate v1.0 gamma 2
* Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)

From: "Dariusz Piatkowski" <dariusz@_NO-SPAM_mnsi.net>

Hi Marcel!


wrote:

> Hi,
>
> On 04.10.2011 05:22, Dariusz Piatkowski wrote:
> > 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?


I am not sure how to look for blocked I/O...is there a particular app/utility I

could try? As far as I can tell and observe, there is no real HDD
activity...the
clock icon comes up in PMView...it goes through the full 'clock-pass' (meaning
the hand pointer circles the clock) and then waits at the '100% completed'
position (12 o'clock)...it does not go-away/clear until the 55 sec time passes,

at which point in time I see a burst of HDD activity. Watching the 'Disk
Monitor' output sure enough, I do see a burst of IOs going out to the disk at
that precise time.

I tried using TOP, Xray and couple of other process monitors but I was unable
to
see what process is actually chugging away during the 55 sec delay. One last
remaining 'trick' is to run this through the 'PM OS/2 Trace' utility, which
will
track the various calls...


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

I have been able to determine that shutting off the cache on the partition in
question does in fact make the problem 'go-away'...as best as I can tell.
However, given that this is my multimedia partition and I primarily use it to
grab the pics off of the cameras, work on movie editting, etc...I'd rather
attempt to use HPFS386 cache.

I did try changing the size of the cache itself, stepped down to 64 MByte, no
difference (maybe I need to go further.... Went through a change to the
timings
themselves, no difference either.

The JFS idea I have considered and attempted in the past. This time around I am

running into a memory issue where attempting to boot with the JFS driver
enabled
causes me a TRAP before the PMSHELL comes up. I only suspect a memory issue
given how much stuff I'm already loading and the fact that I do have a large
HPFS386 cache, 8 60Gig partitions, etc, etc...so yes, I may be pushing this
thing a bit too hard maybe...LOL...

Anyways...thank you for the suggestions...I'll keep on playing around with this

and try the various ideas as they pop into my head...maybe one of these will
result in an answer!
--- NewsGate v1.0 gamma 2
* Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)

From: "Dariusz Piatkowski" <dariusz@_NO-SPAM_mnsi.net>

Folks!

On Sun, 9 Oct 2011 14:34:51 UTC, "Dariusz Piatkowski"
<dariusz@_NO-SPAM_mnsi.net> wrote:

> Hi Marcel!
>


> wrote:
>
> > Hi,
> >
> > On 04.10.2011 05:22, Dariusz Piatkowski wrote:
> > > 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?
>
>
> I am not sure how to look for blocked I/O...is there a particular app/utility
I
> could try? As far as I can tell and observe, there is no real HDD
activity...the
> clock icon comes up in PMView...it goes through the full 'clock-pass'
(meaning
> the hand pointer circles the clock) and then waits at the '100% completed'
> position (12 o'clock)...it does not go-away/clear until the 55 sec time
passes,
> at which point in time I see a burst of HDD activity. Watching the 'Disk
> Monitor' output sure enough, I do see a burst of IOs going out to the disk at

> that precise time.
>
> I tried using TOP, Xray and couple of other process monitors but I was unable
to
> see what process is actually chugging away during the 55 sec delay. One last
> remaining 'trick' is to run this through the 'PM OS/2 Trace' utility, which
will
> track the various calls...
>
>
> > > 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?
>
> I have been able to determine that shutting off the cache on the partition in

> question does in fact make the problem 'go-away'...as best as I can tell.
> However, given that this is my multimedia partition and I primarily use it to

> grab the pics off of the cameras, work on movie editting, etc...I'd rather
> attempt to use HPFS386 cache.
>
> I did try changing the size of the cache itself, stepped down to 64 MByte, no

> difference (maybe I need to go further.... Went through a change to the
timings
> themselves, no difference either.
>
> The JFS idea I have considered and attempted in the past. This time around I
am
> running into a memory issue where attempting to boot with the JFS driver
enabled
> causes me a TRAP before the PMSHELL comes up. I only suspect a memory issue
> given how much stuff I'm already loading and the fact that I do have a large
> HPFS386 cache, 8 60Gig partitions, etc, etc...so yes, I may be pushing this
> thing a bit too hard maybe...LOL...
>
> Anyways...thank you for the suggestions...I'll keep on playing around with
this
> and try the various ideas as they pop into my head...maybe one of these will
> result in an answer!

Just as a FYI...for what it's worth, the latest version of PMView (3.61) is no
longer impacted by this...saves are quite fast on this particualr partition, as

they are on any other ones.
--- NewsGate v1.0 gamma 2
* Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)