Subject: Re: [netatalk-admins] Adrian's afpd server not letting go?

From: Duncan Sinclair <[email-masked]>
Date: Tue, 10 Mar 1998 18:44:58 +0000

>There's a patch against umich 1.4b2 for Solaris. Its description seems
>to match your symptoms. I had to be a little intuitive about applying
>it to netatalk+asun, but I *think* what you need to do is this:

>*** libatalk/asp/asp_getsess.c-
>--- libatalk/asp/asp_getsess.c
>***************
>...

Sorry, I should have said that I have already applied this patch myself.

I can't recall exactly what this fixed, but I fell over it two years ago...

>what I've done is right. It seems to be to my rather naive eye. The
>original patch I found that I adapted to +asun was found at:

It was certainly the right thing as far as I am aware.  Adrian, perhaps
you might include this patch amongst yours?

Thanks,

Duncan Sinclair.

---

From: a sun <[email-masked]>
Date: Tue, 10 Mar 1998 10:58:57 -0800 (PST)

it's already in my current, unavailable snaphost. that snapshot has a
few tweaks to improve solaris support. i'll probably make it available
after i've added in my opendir/readdir/closedir version of
case-insensitive file comparisons.

actually, i would really like some data on the standard size of
people's directories and the machines they're running on. currently,
the only way of properly doing case-insensitive lookups that i can
think of is to actually read the directories, making it an O(n)
operation. bleah. that can be sped up somewhat for future directory
reads by maintaining a hashed list or something. however, that's only
a win if you can be sure that the files won't do something unexpected
under you. i don't think we can make that guarantee with
netatalk. ideas anyone?

-a

---

From: Andras Kadinger <[email-masked]>
Date: Wed, 11 Mar 1998 17:14:16 +0100

> under you. i don't think we can make that guarantee with

I've done some measurements with the routine I sent You before, on a
P133/16MB with Linux 2.0.33.

Empty directory, creat(3)-ing 5000 files:

bash$ time ../catalog -c 5000
0.16user 27.51system 0:29.28elapsed 94%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps

Now there are only a couple of empty files here. Let's build the catalog
file; this involves opendir/readdir/closedir, and finally writes the
resulting list to a .Catalog file in the same directory.

bash$ time ../catalog -l .
0.06user 0.69system 0:03.45elapsed 21%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps

Now we created the catalog file, so next time we can read it directly
and avoid readdir. The result:

bash$ time ../catalog -l .
0.00user 0.11system 0:00.35elapsed 31%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps

Something happens which I am not aware of yet, because in subsequent
invocations, we get:

bash$ time ../catalog -l .
0.00user 0.06system 0:00.07elapsed 85%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps

I used the raw dirent structure:

bash$ ls -l .Catalog 
-rw-------   1 bandit   users     1340536 Mar 11 16:43 .Catalog

Note: most of the involved disk blocks are cached in memory; no sorting
used.

I can not think of any way a file could escape our attention if we base
the updating of the catalog on the directory->mtime > catalog->mtime
comparison modulo races, but I am not an unix expert after all.

Sincerely,
Andras Kadinger
[email-masked]