#2 Working, but incredibly slow


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

    Brad Boyer - 2002-08-19

    Logged In: YES

    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.

  • Brad Boyer

    Brad Boyer - 2002-08-19
    • assigned_to: nobody --> bboyer
  • 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

    Tim (TJ) Snider - 2002-09-23

    Logged In: YES

    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

    Vincent Beffara - 2002-10-02

    Logged In: YES

    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

    Tim (TJ) Snider - 2002-10-03

    Logged In: YES

    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,


  • Tim (TJ) Snider

    Tim (TJ) Snider - 2002-10-03

    Logged In: YES

    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

    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?


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks