#2 Working, but incredibly slow

[Anonymous]

It seems to work fine, and I can read data from files,
but at an unusably slow rate. Less than 1MB files take
in the order of half a minute to fully read.

Any ideas?

[Brad Boyer]

Logged In: YES
user_id=73195

Yes, it's slow. It probably won't get fixed until the next
major rewrite. The problems causing this are pretty deep in
the code, and at this point, correctness is more important
than speed.

[Nobody/Anonymous]

Logged In: NO

Couldn't just make it a little faster? Anything is better
than the speed I'm currently getting.. I'm using it for an
embedded automated software license scan, which basically
goes through every file on each partition and I think to do
one machine would take more than a day, which is far too long :<

Anyhow, thanks for the good work on this project. HFS+
support has been needed for a long time.

[Tim (TJ) Snider]

Logged In: YES
user_id=382485

I am experiencing similar slowdowns, on a RH 7.3 box,
regardless of partition. Directory access ie. filenames seem
to be fine, but data transfer is really slow. But everything
seems to work otherwise.

[Vincent Beffara]

Logged In: YES
user_id=130268

I noticed that too, but only if the hard drive(s) are
otherwise idle. So when I
have to, I just run "find /" in the background, and the
speed becomes quite correct while it is physically reading
sth from the disk.

No idea what might be causing this, though.

[Tim (TJ) Snider]

Logged In: YES
user_id=382485

Hmmm, perhaps I'm wrong, but that sounds like we're busy waiting or
something, ie. not getting requests filled unless there's other activity. Is
the module working with the disk cache correctly or is there some way in
which it should be listening for wakeups/completion notification?

Just wondering,

TJ

[Tim (TJ) Snider]

Logged In: YES
user_id=382485

Well instead of speculating I decided to do some, admittedly
unscientific, stopwatch tests.

On my test box (RH 7.3, PII/350, etc.) using "cp src dst";

A 31 MB sit file takes ~ 15 sec to xfer from a HFS+ vol to a EXT2 vol.
The same sit file takes ~ 3 sec to xfer from a EXT2 vol to a diff EXT2 vol.
(I've tried to take into account caches etc. so the numbers are after a
fresh boot or mount of the volume.)

Additionally trying to do the copy(from HFS+ to EXT2) after having copied
it once already, is only a few ~2-3 sec so it seems that the block cache
is working fine with the HFS+ module.

So HFS+ read access is roughly 4 times slower than EXT2 right now, at
least on my machine given the way that I've tested it, which given all the
work that has gone into getting EXT2 fast, that shouldn't be that
surprising.

Although it's been a while since I poked that deep into the MacOS,
wasn't it keeping an extent cache associated with the FCB's?
I believe that the FCBExtRec kept the first few extents, was this also
true for HFS+?
And there was also the BTree cache as well, so is it possible that part of
the difference is extent lookup overhead and conversion to Inodes?