Subject: Re: Re: [netatalk-admins] We're doing benchmarks (tips, tricks, help, info)

From: Mark Donnelly <[email-masked]>
Date: Sat, 28 Mar 1998 09:40:33 -0600

Eddie Irvine:

>
>As I said, AppleShare is a good product, and I expect a G3 will
>blow your linux machine out of the water if filesharing speed is
>the only issue. 
> 

Of course, you could install linux on the G3 as well.  Maybe as 
an external disk, that you could mount when you were doing the 
testing of linux.  That would probably blow almost anything other
than an alpha out of the water.

But, you would still have the problem (as brought up before) that
netatalk actually has to translate to get its resource fork, 
whereas MacOS just reads it off the disk.

--Mark

---

From: Andras Kadinger <[email-masked]>
Date: Sat, 28 Mar 1998 18:23:29 +0100

Mark,

> whereas MacOS just reads it off the disk.

I must admit, I do not understand, what do You mean by 'translating'
here, and why netatalk needs to do it. Could You please explain?

Sincerely,
Andras Kadinger
[email-masked]

---

From: Mark Donnelly <[email-masked]>
Date: Sat, 28 Mar 1998 14:27:15 -0600 (CST)

> here, and why netatalk needs to do it. Could You please explain?

Sure!

Unless you have a hfs volume mounted (which is probably not the case),
UNIX doesn't actually *have* a resource fork.  Netatalk emulates it with a
".AppleDouble" directory that contains an identically-named resource fork
file, but those aren't necessarily there.  So, netatalk has to make it up
as it goes along sometimes.  It uses the file extensions mapping in the
AppleVolumes file to provide a filetype/creator automatically.  (and then
caches that to disk).

But...

Even when the .AppleDouble resource file does exist, you're talking about
at least two separate file accesses to look at one file.  On the other
hand, the Mac doubtless has optimizations in the OS to speed up the way
that it access data/resource forks.

So, that's pretty well the difference.

--Mark
    "I think so Brain, but if they called them sad meals, then nobody
        would buy them." 
   --Pinky

---

From: Andras Kadinger <[email-masked]>
Date: Sat, 28 Mar 1998 22:22:10 +0100

[email-masked] wrote:
> I don't think there's a big lose on file reads and writes.  There is,
> however, a big lose on enumerates (the AFP equivalent of Unix 'ls').
> In this case, afpd must open the AppleDouble header file for each file
> in the directory.  Very expensive, especially if the directory is NFS
> or AFS mounted.

In fact I was thinking about caching type/creator/comment/icon/other
miscellaneous information with the data the catalogueing daemon proposed
by Adrian would collect.
Adrian, what do You think? This way all the necessary information an
enumerate I assume would need could be in one place, hopefully sparing a
lot of disk seek time - my biggest complaint about netatalk performance
was always the excessive seeking during enumerates, which eats away
precious disk bandwidth from more productive uses.

Sincerely,
Andras Kadinger
[email-masked]
PS: Wesley, did You receive my second message regarding the website
creation for Adrian's version?

---

From: [email-masked]
Date: Sat, 28 Mar 1998 16:09:29 -0500

> From:    Mark Donnelly <[email-masked]>
> To:      Andras Kadinger <[email-masked]>

> It uses the file extensions mapping in the

Actually, it only caches certain information to disk.  In particular,
it avoids caching the type and creator, so that they can be changed in
the extension map.

:wes

---

From: Andras Kadinger <[email-masked]>
Date: Sat, 28 Mar 1998 22:22:10 +0100

Sincerely,
Andras Kadinger
[email-masked]

---

From: [email-masked]
Date: Sat, 28 Mar 1998 16:09:29 -0500

:wes