Subject: [netatalk-admins] Sherlock takes a LONG time

From: Tom Kunz <[email-masked]>
Date: Tue, 23 Nov 1999 14:54:46 -0500

Everybody,
	I am having a very strange problem with a customer's netatalk
installation.  He is sharing an 8G partition, with about 2G of it used,
from his Red Hat Linux 6.0 server to about 15 Mac's.  He's using
netatalk-1.4b2+asun2.1.3-4.i386.rpm.  Saving and copying files to the
Linux machine is as quick as ever, but when he uses Sherlock to find
files on it, it takes an absolutely ridiculous amount of time.  Up until
the other day, Sherlock was nice and fast, equally as fast as when
searching any other network volume.  Now all of a sudden, Sherlock is
insanely slow (up to 2 hours!) when searching this netatalk volume, but
as fast as ever when searching non-netatalk network volumes.  Afpd has
been configured to allow up to 75 concurrent users, but that's about the
only thing different from this and a the stock installation out of the
rpm.
	Anybody know what is happening here?  Any suggestions would be greatly
appreciated.
Thanks,
Tom

-- 
Tom Kunz    Tool Developer   Software Consulting Services
PGP Key http://www.users.fast.net/~tkunz/pgp.html
1452 1F99 E2BB 632E  6EAE 2DF0 EF11 4DFC
DB62 7EBC 3BA0 6C40  88C0 C509 DA85 91B4  D5E9 EFD3

---

From: ME <[email-masked]>
Date: Tue, 23 Nov 1999 14:44:34 -0800 (PST)

The obvious tech support questions:
Between the time before when searching the netatalk volume when it was
fast, and now when it is slow:

Has any new hardware been installed on the Linux Box that is running
Netatalk?
Has there been a change in kernels being used?
Has there been a modification in network interface bindings?
Has the client had its OS upgraded, or updated with new software?
When this search is taking a long time, run "uptime" at the command prompt
no the linux box. What umbers does it report when it starts taking a long
time? Is there a heavy load on the system?
Is the hard disk on the server doing a lot of seeking (IDE, or Single CSI
Disk not HW RAID) while serving files to many users?
When fsck is run on the volume being shared, what percent of the partition
files are fragmented?
Have you included special IP filtering mechanisms for firewalls, and
packet analysis?
Did you recently uuse IP Aliasing and bing more IP addresses to any given
interface? (not ikel to case a problem)
When the Linux box is powred down, do any other machines respond to a ping
of the servers IP address?
Is there a problems with the port being used on the hub/switch?
Are you using a switched network?
Did the network administrator recently change how the switches are
configured store and forward, cut through filtering, layer3 switches etc?

If it was working quickly before, and is not searching quickly now,
*something* must have changed. What is it that has changed?

-M
*(There are more questions, but maybe one of these will start us in the
right direction.,..)
--------------------------------------------------------------------------
Systems Department Operating Systems Analyst for the Ruben Salazar Library
              of California State University at Sonoma.
  /UNIX(/BSD/SysV)\N_NW[.]VMS\WNTS\WNTW\W95\W311\WFWG\DOS:MacOS/NeXTSTEP  
--------------------------------------------------------------------------

On Tue, 23 Nov 1999, Tom Kunz wrote:
> Subject: Sherlock takes a LONG time
> 
> Everybody,

---

From: Tom Kunz <[email-masked]>
Date: Tue, 23 Nov 1999 17:51:51 -0500

ME wrote:
> ...

	In a word: No.  The obvious questions have an obvious answer.  That's
why I'm posting here.  For the not-so-obvious answers.  No changes to
either clients or server.  No upgrades, no changes, no nothing.  I've
already done the silly tech support blah blah blah and eliminated all
that stuff.  Wouldn't I be a horrificly lazy fool to not exhaust all the
"obvious tech support" possiblities before posting here?  Something did
not *necessarily* change on the network to cause this problem.  Latent,
hidden bugs are present in many software endeavors, thus nothing *had*
to change to cause this.
	Which brings me to netatalk.  The magic number of roughly 2G worth of
used disk space sounds like it *might* be some sort of arbitrary limit,
or perhaps imposed by accidental mis-prototyping of a variable.  I know
others here are using much larger systems with much more space, but
perhaps that rpm contains code with a boo-boo.  Also, NT servers on the
same subnet are using some apple-sharing type of product, similar in
functionality to netatalk, but with no performance problems, which says
that it is isolated to the single machine, not universally a problem
throughout the net.  Like I said, file saving and copying to/from the
server are fine, also indicating some kind of problem in how Sherlock
interacts with netatalk.  It happens *only* with *Sherlock*, and not
with other stuff.  Things like Samba, ftpd, telnetd, remote X
connections, and so forth have no problems.  It's not that Sherlock
never returns, it's that Sherlock takes a darn long time, like up to 2
hours, to search an 8G volume with 2G of files in it. It's not an issue
of SCSI vs IDE, as even an MFM or ST-506 disk won't have *THAT* much
performance difference!

Tom

---

From: ME <[email-masked]>
Date: Tue, 23 Nov 1999 16:23:14 -0800 (PST)

Elimination of all of the items mentione helps others to address your
question.

I have multiple 8Gb volumes shared with ix86 based Linux server with
recent stable asun netatalk setup.

4 to 6 Gb are filled on the 8BGb volumes and users have reported no
problems with speed for finding files on our servers.

We use the built in "Find File" with System 8.1, 8.61, and 9, and have
found no differences in speed for doing searches: they have all takken
about the same amount of time.

Here is another suggestion since you know the other basic suggestyions
have been reviewed:

There can be a significant performance cost in dealing with resource and
data form recombination when copying files to and from a netatalk volume.

IF someone has recently dumped a lot (i mean a lot) of small files on your
volume, this could mean an increas in searching time, but I don't think it
would move to 2 hours.

Could it be that you have a few damaged files on the volume that netatalk
is having difficulty in serving? Maybe make a directory in art of the tree
un-readable, and try using sherlock to see if you can isolate the problems
in the search taking tso long to a particular group of files...

There were issues brought up before about spanning tree with seeing shares
in AppleTalk zones properly, but that is probably not your problem...
There were issues a long while back with AntiVirus Software's automatic
running that caused problems, but this is probaby not your problem
eaither.

I assume you are running with Mac OS 8.1 or better so as to rule out some
of the problems associated with earlier System 7.x series systems and
understanding large network volumes....

Have you tried to create less than 2Gb shares to see if your sherlock
problems go away? Maybe even create a 1.5Gb image, losetup with loopback
interface and mount it, then share it and copy the files over to it just
for testing sake (if you cannot get a separate disk or partition that is
1.5Gb.)

Hey, you are the one that is *there* and has done all of the testing. All
I can do is provide suggestions based on the input you offer me. I did not
mean to offend you with a list of common questions. Your original message
did not cover those issues, so to move us towards a direction of solution,
I included them.

-ME

 On Tue, 23 Nov 1999, Tom Kunz wrote:
> Subject: Re: [netatalk-admins] Re: Sherlock takes a LONG time
> 
> ME wrote:
> >

---

From: a sun <[email-masked]>
Date: Tue, 23 Nov 1999 15:11:41 -0800

umm. netatalk is slow on finds because it doesn't have the FPCatSearch
command implemented. as a result, you have to spend a bunch of time
descending directories and poking at files. needless to say, that's
much slower than a database query. fyi, that's one of the reasons why
i broke the DID stuff. i wanted to be able to implement FPCatSearch in
a straightforward manner. a database that only did DID was too limited
for that use.

let's just say that 2GB probably corresponds to a fairly large number
of files. you'll notice that directory lookups are pretty slow for
directories with a lot of files in them. again, i hope to correct this
eventually, but it's a post-asun2.2 feature.

in other news, if someone would conveniently send me the kerberos
authentication spec, that would speed things up for an asun2.2 for
me. 

-a
a believer in truth in advertising.