HPFS386 cache size...surprising results!
Dariusz Piatkowski
I thought I'd post something...a bit of a surprising result to me initially...in
retrospect these kind of make sense I suppose.
Alright, so I'm using the hpfs386 FS here, Asus A7N8X Deluxe mb, with Athlon
Barton 2.3 Gig, 2 Gig DDR Ram, main OS2 drive is a WD VelociRaptor 300 Gig SATA
drive. I am not using the mb SATA controller chip because I kept on having
problems with it, instead I am using a Promise TX300 controller using the PCI
bus.
Anyways, for some time now I have been running a fairly large 512MB cache for
this filesystem. My main partition is the full 64Gig...and it has been working
pretty well on the whole. I did notice however that moving large files, such as
CD images for example would cause the CPU to spike to 100% for up to about 30
sec...strange I thought, given that SysBenc reports a very low CPU utilization
during DISK access.
On a whim I decided to play around with the cache size. I ran some tests, using
the large 700 MB file as a test file. I copied the file on the same physical
hard disk, but from 1 partition to another, both of them using the hpfs386 cache
sub-system, both LAZY WRITE enabled.
To my surprise as I started shrinking the cache down the performance improved.
In fact, best performance was obtained running a 128MB cache here. The file
moves got down to about 20 secs., the benefit being that I no longer incurr the
100% CPU spike...there is basicaly barely any CPU utilization, as expected.
My only conclusion from the above results is that the large cache must have
caused the file data to be loaded into memory first, followed by some internal
processing and finally a write out to the disk...with the smaller cache that
does not appear to be hapenning.
I always thought that the smaller cache size was OK back in the days of machines
with barely any memory. Apparently, in the case of hpfs386 growing the cache
size can in fact be detrimental. I have read several times that hpfs386 was
tuned for a very small cache and that may be what I am seeing on my machine.
I'm curious what other people are using? And most important of all (to me) how
does it compare to the JFS?
James J. Weinkam
>
> To my surprise as I started shrinking the cache down the performance improved.
> In fact, best performance was obtained running a 128MB cache here. The file
> moves got down to about 20 secs., the benefit being that I no longer incurr the
> 100% CPU spike...there is basicaly barely any CPU utilization, as expected.
>
they are needed again in the near future the mamory copy can be used rather
than rereading the sector from the physical disk. This can yield big time
savings for portions of files that are consulted often. Once the cache fills
up, whenever a sector (or whatever size allocation unit the cache systen uses)
is read the system must decide which already cached sector to kick out of the
cache (the victim) to make way for the new sector. Moreover, if lazy write is
enabled and the victim sector has been altered but not yet written out, it
must be written to disk before the cache sector can be reused. Usually the
victim sector is chosen using a LRU (least recently used) algorithm. The
larger the cache, the larger the data structure that must be maintained to
make all this work, and the longer it takes to make it happen. Copying a file
larger than the cache results in total cache replacement with sectors from the
end of the file that are unlikely to be read again before they get replaced so
the cache doesn't buy you anything and you're better off without it.
As to comparison of HPFS and JFS, my experience has been that JFS is far
superior. I no longer have anh HPFS volumes on any of my systems. Now that
bootable JFS is available even the boot volume can be JFS. Everything is faster.
Dave Yeo
I wonder how HPFS386 allocates 512 MBs. I doubt it knows about high
memory and with only a 512 MB address space that is probably got some
other stuff in it it may be doing the equivalence of bank switching or
something similar. This may be part of the high CPU usage though James
makes some good points as well.
JFS does know about the high memory so should be able to allocate over a
gigabyte without problems on most machines though at some point it will
meet up with system memory and become unstable
Dave
Marcel Müller
Dave Yeo wrote:
> On 10/04/09 08:14 pm, Dariusz Piatkowski wrote:
>> To my surprise as I started shrinking the cache down the performance
>> improved.
>> In fact, best performance was obtained running a 128MB cache here. The file
>> moves got down to about 20 secs., the benefit being that I no longer incurr the
>> 100% CPU spike...there is basicaly barely any CPU utilization, as expected.
hmm, 35MB/s through HPFS386 with transfers on one physical disk, you
should be very lucky. You move with 70MB/s over the bus.
>> My only conclusion from the above results is that the large cache must have
>> caused the file data to be loaded into memory first, followed by some internal
>> processing and finally a write out to the disk...with the smaller cache that
>> does not appear to be hapenning.
Well, HPFS386 is not optimized for that large caches. Probably some
internal structures have bad scalability.
>> I always thought that the smaller cache size was OK back in the days of machines
>> with barely any memory. Apparently, in the case of hpfs386 growing the cache
>> size can in fact be detrimental. I have read several times that hpfs386 was
>> tuned for a very small cache and that may be what I am seeing on my machine.
>>
>> I'm curious what other people are using? And most important of all (to me) how
>> does it compare to the JFS?
JFS is significantly faster with large files. In my case about 50%.
However, concerning disk transfers on the same physical drive the speed
is usually very sensitive to the access pattern. And 35MB/s are quite
uncommon.
So If you want to test the file system you should prefer to use
different physical disks as source and destination.
> I wonder how HPFS386 allocates 512 MBs. I doubt it knows about high
> memory and with only a 512 MB address space that is probably got some
> other stuff in it it may be doing the equivalence of bank switching or
> something similar. This may be part of the high CPU usage though James
> makes some good points as well.
No idea, all I know is that HPFS386 uses some special way for memory
allocation, because many restrictions for boot time memory do not apply.
> JFS does know about the high memory so should be able to allocate over a
> gigabyte without problems on most machines though at some point it will
> meet up with system memory and become unstable
I have not seen a large benefit form excessive cache sizes. The speed
limiting factor seems to be the transaction log.
Marcel
Christian Hennecke
Well, I don't think that HPFS386 was tuned for very small cache sizes.
HPFS certainly was. I can confirm your experience, though. As James said
such large files are not a good way of measuring file system
performance.
My experience is that which a cache size of 64 to 128 MB HPFS386 is a
bit faster than JFS if many small to medium size files are accessed --
which probably is the more realistic test scenario. However, I use JFS
these days because it supports partitions over 64 GB and files over 2
GB, plus I need to enable EARLYMEMINIT in CONFIG.SYS.
--
"I smell blood and an era of prominent madmen." - W.H. Auden
Marty
[snips]
> To my surprise as I started shrinking the cache down the performance improved.
> In fact, best performance was obtained running a 128MB cache here. The file
> moves got down to about 20 secs., the benefit being that I no longer incurr the
> 100% CPU spike...there is basicaly barely any CPU utilization, as expected.
>
> My only conclusion from the above results is that the large cache must have
> caused the file data to be loaded into memory first, followed by some internal
> processing and finally a write out to the disk...with the smaller cache that
> does not appear to be hapenning.
Moving large files is a nightmare scenario for caches. The only cache
hits are from read-ahead operations. All the rest are misses.
Lazy writes on HPFS are what spike your CPU. You'll notice that for the
first second or two of the transfer, your CPU is ok. Once the lazy
writes are forced to start committing data, the disk starts to thrash
and the system starts to chug badly (audio will hiccup if it's playing,
high priority threads will not get runtime, etc.). Try turning off lazy
writing and you will so a noticable difference when transferring a large
file. I don't recommend running your system like this in general, but
run it as a test to see the difference. The CPU load will be much lower
and the hiccups will be completely gone.
I do not see these effects so pronounced on JFS filesystems. I saw
extreme versions of this effect with 16-bit HPFS, but it seems that
HPFS386 also shares this foible.
--
Reverse the parts of the e-mail address to reply by mail.
Ilya Zakharevich
> As to comparison of HPFS and JFS, my experience has been that JFS is far
> superior.
It would be much more superior if it would not crash on file deletion.
(A major coincidence? 10min ago I got a second partition with an
undeletable file...)
And things would be much much better if it could handle directories
with 1000 files without a major slowdown...
Ilya
Marcel Müller
> I do not see these effects so pronounced on JFS filesystems.
Oh,, write several thousands of small files to a JFS volume and after
some time the system will lock up for some minutes or so with continuous
disc activity. Extraction of a cddb archieve is a good test case for
that. Slower than on HPFS386 by a factor.
But you are right with respect to large files.
Marcel
Ilya Zakharevich
> On 2009-10-05, James J. Weinkam <j...@cs.sfu.ca> wrote:
>> As to comparison of HPFS and JFS, my experience has been that JFS is far
>> superior.
>
> It would be much more superior if it would not crash on file deletion.
> (A major coincidence? 10min ago I got a second partition with an
> undeletable file...)
In fact, this was not as bad as I expected. JFS would crash if I
attempted to delete this file; however, after a few hickups, chkdsk
managed to find this file itself, and delete it without any manual
intervention.
So I'm back to one partition with an undeletable file...
Yours,
Ilya
Christian Hennecke
<nospam...@ilyaz.org> wrote:
> >> As to comparison of HPFS and JFS, my experience has been that JFS is far
> >> superior.
> >
> > It would be much more superior if it would not crash on file deletion.
> > (A major coincidence? 10min ago I got a second partition with an
> > undeletable file...)
>
> In fact, this was not as bad as I expected. JFS would crash if I
> attempted to delete this file; however, after a few hickups, chkdsk
> managed to find this file itself, and delete it without any manual
> intervention.
>
> So I'm back to one partition with an undeletable file...
Ilya, which version of JFS are you using? I remember having such issues
with earlier versions. Are there any special characters in the file
name?
Ilya Zakharevich
On 2009-10-06, Christian Hennecke <christian...@os2voice.org> wrote:
> Ilya, which version of JFS are you using?
Signature: @#IBM:14.100e#@ IBM OS2 JFS retail bld
Vendor: IBM
Revision: 14.100
File Version: 14.100
Description: IBM OS2 JFS retail bld
> Are there any special characters in the file name?
"Absolutely normal" ASCII name... The file is readable. I have a
dozen other files in the same series with names differing by digits
only, and they were deleted OK (after I did a one-by-one deletion to find
which one of the series would crash JFS...).
Yours,
Ilya
Trevor Hemsley
<nospam...@ilyaz.org> wrote:
> ["Followup-To:" header set to comp.os.os2.setup.storage.]
> On 2009-10-06, Christian Hennecke <christian...@os2voice.org> wrote:
>
> > Ilya, which version of JFS are you using?
>
> Signature: @#IBM:14.100e#@ IBM OS2 JFS retail bld
> Vendor: IBM
> Revision: 14.100
> File Version: 14.100
> Description: IBM OS2 JFS retail bld
Ancient!
Build Level Display Facility Version 6.10.480 Oct 6 2000
(C) Copyright IBM Corporation 1993-2000
Signature: @#IBM:14.105#@ IBM OS2 JFS retail bld
Vendor: IBM
Revision: 14.105
File Version: 14.105
Description: IBM OS2 JFS retail bld
--
Trevor Hemsley, Brighton, UK
Trevor dot Hemsley at ntlworld dot com
Christian Hennecke
<nospam...@ilyaz.org> wrote:
> ["Followup-To:" header set to comp.os.os2.setup.storage.]
> On 2009-10-06, Christian Hennecke <christian...@os2voice.org> wrote:
>
> > Ilya, which version of JFS are you using?
>
> Signature: @#IBM:14.100e#@ IBM OS2 JFS retail bld
> Vendor: IBM
> Revision: 14.100
> File Version: 14.100
> Description: IBM OS2 JFS retail bld
That *should* be ok. I remember that to get rid of all problems after
updating JFS I had to reformat the volume with the new version of JFS.
James J. Weinkam
> On 2009-10-06, Ilya Zakharevich <nospam...@ilyaz.org> wrote:
>> On 2009-10-05, James J. Weinkam <j...@cs.sfu.ca> wrote:
>>> As to comparison of HPFS and JFS, my experience has been that JFS is far
>>> superior.
>> It would be much more superior if it would not crash on file deletion.
>> (A major coincidence? 10min ago I got a second partition with an
>> undeletable file...)
I have never seen a file deletion problem with JFS. Are you running the latest
version? What file are you having trouble deleting?
Ilya Zakharevich
>> Signature: @#IBM:14.100e#@ IBM OS2 JFS retail bld
>> Vendor: IBM
>> Revision: 14.100
>> File Version: 14.100
>> Description: IBM OS2 JFS retail bld
> That *should* be ok. I remember that to get rid of all problems after
> updating JFS I had to reformat the volume with the new version of JFS.
Frankly speaking, I do not see how a need to reformat would prove
anything. I'm running with 14.100 for 3-4 years, with average 1TB of
disks used. In this time, I saw one SYS0030 for file read (do not
know enough to judge whether it is a JFS fault, or just a disk
defect), and one "persistably undeletable" file.
Obviously, with such a low frequency of bugs, reformatting will HIDE a
problem - even if it is done with the same version... (I'm not saying
that some version may be better than 14.100 - just that QA with a low
frequency of irreproducible errors is not a simple matter...)
Yours,
Ilya
Ilya Zakharevich
>> Signature: @#IBM:14.100e#@ IBM OS2 JFS retail bld
>> Vendor: IBM
>> Revision: 14.100
>> File Version: 14.100
>> Description: IBM OS2 JFS retail bld
>
> Ancient!
>
> Build Level Display Facility Version 6.10.480 Oct 6 2000
> (C) Copyright IBM Corporation 1993-2000
> Signature: @#IBM:14.105#@ IBM OS2 JFS retail bld
> Vendor: IBM
> Revision: 14.105
> File Version: 14.105
> Description: IBM OS2 JFS retail bld
Hmm, this is XR_c006... Is it going to work on no-LVM system?
Thanks,
Ilya
Trevor Hemsley
That one comes from the eCS download site as jfs14105.exe and I think is their
recommended JFS level. I am fairly sure it's one of the last builds that Scott
did before he stopped working on OS/2. Your build appears to be the one that I
have downloaded as
25-08-04 11:23a 184402 0 jfs20040925.zip
with files inside dated 19-08-2004. The files inside jfs14105.exe are dated
mostly 25-01-2006.
Some of Scott's testcase builds had a readme file that listed the fixes so if
you can find one of those closer to 14.105 then it might be illuminating.
Marty
From that information, I would guess that the name is a complete red
herring. The reason it would trap the system would be something in the
filesystem structure itself, probably the directory entry points to
something evil. Can you access the file in any other way besides your
attempts to delete it? Can you read it, overwrite it, rename it? If
all of these cause the trap, then there is definitely something horribly
wrong with the directory entry.
Ilya Zakharevich
>> Vendor: IBM
>> Revision: 14.100
>> File Version: 14.100
>> Description: IBM OS2 JFS retail bld
>
> Ancient!
>
> Build Level Display Facility Version 6.10.480 Oct 6 2000
> (C) Copyright IBM Corporation 1993-2000
> Signature: @#IBM:14.105#@ IBM OS2 JFS retail bld
> Vendor: IBM
> Revision: 14.105
> File Version: 14.105
> Description: IBM OS2 JFS retail bld
Same difference! With both versions, an attempt to delete file
would lock the computer hard (mouse pointer does not move, beeps on
any keyboard access) after 2-3 sec.
Yours,
Ilya
Ilya Zakharevich
>> "Absolutely normal" ASCII name... The file is readable. I have a
> something evil. Can you access the file in any other way besides your
> attempts to delete it? Can you read it, overwrite it, rename it?
As I said, the file is readable. Renaming works. Did not try to
write; my next attempt would be to truncate().
Yours,
Ilya
Ilya Zakharevich
> As I said, the file is readable. Renaming works. Did not try to
> write; my next attempt would be to truncate().
Interesting: I tried to truncate() the last GiB off. No lockup of the
system - it remains usable - with 0% CPU usage, and no disk access
light showing.
truncate() blocks forever; meanwhile one cannot list the directory of
the file.
CAD shows the message "The system is rebooting, please wait", then
blocks forever.
Thanks,
Ilya
Ruediger Ihle
> I wonder how HPFS386 allocates 512 MBs. I doubt it knows about high
> memory and with only a 512 MB address space that is probably got some
> other stuff in it it may be doing the equivalence of bank switching or
> something similar.
The 512MB virtual address limit does not apply to device drivers
and file systems. They allocate their (virtual) memory above
VIRTUALADDRESSLIMIT. So you only run into trouble, if you set this
value too high...
There is another restriction, which has to do with physical memory
and a somewhat broken implementation of EARLYMEMINIT. AFAIK, this
causes HPFS386 to fail when EARLYMEMINIT is enabled in CONFIG.SYS.
--
Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
http://www.s-t.de
Please remove all characters left of the "R" in my email address
Dariusz Piatkowski
> On Mon, 5 Oct 2009 06:21:37 UTC, Dave Yeo <dave....@gmail.com> wrote:
>
> > I wonder how HPFS386 allocates 512 MBs. I doubt it knows about high
> > memory and with only a 512 MB address space that is probably got some
> > other stuff in it it may be doing the equivalence of bank switching or
> > something similar.
>
> The 512MB virtual address limit does not apply to device drivers
> and file systems. They allocate their (virtual) memory above
> VIRTUALADDRESSLIMIT. So you only run into trouble, if you set this
> value too high...
> There is another restriction, which has to do with physical memory
> and a somewhat broken implementation of EARLYMEMINIT. AFAIK, this
> causes HPFS386 to fail when EARLYMEMINIT is enabled in CONFIG.SYS.
I have VIRTUALADDRESSLIMIT=2048, and previously was not able to run HPFS386 if
EARLYMEMINIT was set to TRUE.
Dariusz Piatkowski
<christian...@os2voice.org> wrote:
> Well, I don't think that HPFS386 was tuned for very small cache sizes.
> HPFS certainly was. I can confirm your experience, though. As James said
> such large files are not a good way of measuring file system
> performance.
>
> My experience is that which a cache size of 64 to 128 MB HPFS386 is a
> bit faster than JFS if many small to medium size files are accessed --
> which probably is the more realistic test scenario. However, I use JFS
> these days because it supports partitions over 64 GB and files over 2
> GB, plus I need to enable EARLYMEMINIT in CONFIG.SYS.
Yeah, I agree with you. Back in the day 128MB disk cache would not have been
considered large. Today however, things have changed. My work laptop machine,
which has 2Gig of RAM and is running NTFS under Win XP Pro is routinely running
about 750K 'system file cache'. I am no windows expert but I assume that means
the file system cache and is analogous to the HFPS cache in OS/2.
Dariusz Piatkowski
> Moving large files is a nightmare scenario for caches. The only cache
> hits are from read-ahead operations. All the rest are misses.
Yes, this is probably the worst case scenario indeed.
> Lazy writes on HPFS are what spike your CPU. You'll notice that for the
> first second or two of the transfer, your CPU is ok. Once the lazy
> writes are forced to start committing data, the disk starts to thrash
> and the system starts to chug badly (audio will hiccup if it's playing,
> high priority threads will not get runtime, etc.). Try turning off lazy
> writing and you will so a noticable difference when transferring a large
> file. I don't recommend running your system like this in general, but
> run it as a test to see the difference. The CPU load will be much lower
> and the hiccups will be completely gone.
>
> I do not see these effects so pronounced on JFS filesystems. I saw
> extreme versions of this effect with 16-bit HPFS, but it seems that
> HPFS386 also shares this foible.
I have to disagree with you on this. I've done this testing along side using
Trevor's 'PM Disk Monitor' utility which shows the reads/KBs read/written
from/to any system disk.
The CPU spikes right away and the disk monitor consistently reports lower
transfer rates. I am not seeing this with the smaller cache at all...and given
that the lazy write settings remain the same I should at least see something
similiar, albeit on a smaller scale. Still, 100% CPU utilization vs. 'barely
there' is quite a significant difference.
I wish there were some utilities out there that would identify internally what
the cache logic is executing...
Your 'lazy write' theory is easy to test though...I'll give that a try next.
J. Clarke
Ordinarily NT and its descendants (2K, XP, Vista, Windows 7, etc) will use
all RAM that is not otherwise allocated for disk cache. On the machine I'm
using now that's about 6 gig of cache. If you're only seeing 750K of cache
something is wrong.
Will Honea
Don't forget that cache design is important, not just the size. Some cache
managers are tuned for many small blocks (files) while others are tuned for
a read-ahead operation. There are many, many ways to skin the cat, but
tests will show that for a given cache manager there is a sweet spot where
more available cache space is just as much a drag on throughput as too
little - the management overhead catches up to the increased throughput at
some point. I can recall spending a lot of time with OS/2 servers testing
various disk cache sizes with many small files, then huge file blocks, then
random requests just to find what worked best for a given load. Bigger is
not always better.
--
Will Honea
Ilya Zakharevich
>> (C) Copyright IBM Corporation 1993-2000
>> Signature: @#IBM:14.105#@ IBM OS2 JFS retail bld
>> Vendor: IBM
>> Revision: 14.105
>> File Version: 14.105
>> Description: IBM OS2 JFS retail bld
> Hmm, this is XR_c006... Is it going to work on no-LVM system?
Answering my own question: No, this version of UJFS.DLL refuses to
create *new* JFS partitions without LVM. However
a) it works fine with existing non-LVM partitions;
b) if my older LVM-infectation-cleaned version is on LIBPATH,
formatting works fine even without LVM (so: there is no version
check between UJFS.DLL and JFS.IFS).
Thanks,
Ilya
Sjoerd Visser
<dariusz@_NO-SPAM_mnsi.net> wrote:
> > The 512MB virtual address limit does not apply to device drivers
> > and file systems. They allocate their (virtual) memory above
> > VIRTUALADDRESSLIMIT. So you only run into trouble, if you set this
> > value too high...
> > There is another restriction, which has to do with physical memory
> > and a somewhat broken implementation of EARLYMEMINIT. AFAIK, this
> > causes HPFS386 to fail when EARLYMEMINIT is enabled in CONFIG.SYS.
>
> I have VIRTUALADDRESSLIMIT=2048, and previously was not able to run HPFS386 if
> EARLYMEMINIT was set to TRUE.
>
I agree. This is was also what I expercienced.
As Christian pointed the kernel space HPFS driver does not in theory
has the 512 MiB limit, but in (my) practice the highest HPFS cache
size I could set was much less then 512 MiB. And I wonder if the
driver was tested for systems with > 1 GiB RAM.
cachesize = 192000
; grotere cache geeft probleem met framebufers van EmperoarTV (VRAM of
JFS verkleinen)
; cachesize = 256000
useallmem = YES
; maxheap=2048
; maxheap=4096
; maxheap=8196
maxheap=12288
PS Notice that the VAL (program space) + HPFS and other like JFS
cache + VRAM + other needed ACPI BIOS ROM + OS/2 other system space
should be less then 4 GiB. This is the to programs offered virtual
adress space limit of any 32 bits OS.
--
Greetings,
Sjoerd Visser
Hendrik Schmieder
Ilya Zakharevich
> Did yout try the jfs utils from ecomstation.ru ?
I tried JFSCHK32.EXE (do not know what else you might mean), but
AFAIK, it does exactly the same as chkdsk...
Thanks,
Ilya
Hendrik Schmieder
Ilya Zakharevich schrieb:
Jrescuer
Hendrik