Subject: Sherlock from Mac OS 9 slow

From: "Bernard M. Piller" <[email-masked]>
Date: Thu, 29 Mar 2001 17:25:30 +0200

Hi,

I have a RedHat 6.2 Server running and while the server itself is very fast,
Sherlock is extremly slow when doing searches from Mac OS 9 clients. The
server volumes are large, with about 50GB of data on every drive.

I know there where problems with netatalk not supporting the FPCatSearch
function which Sherlock uses.

Is this fixed in some version of netatalk out there on the net or does
someone know another solution to this problem?

Bernard

-- 
www.bmpsystems.com
 +43 664 336 9196

---

From: Vic Landi <[email-masked]>
Date: Thu, 29 Mar 2001 15:32:33 -0500

I've been looking for a solution as well, however I'm afraid there is not
one yet.  The problem is that the Mac OS uses a db to make the searches
faster (a hidden file that makes records on where everything is)  So when
you do a sherlock search on a netatalk server you actively search through
the directory tree, taking a lot of time.  Solutions to this have been
posed... These include the ext3 file system (if and when it comes out) and
rasierfs (this I'm unsure of)

However, from what I saw in the public beta of OS X, even that was slower,
but not as slow... could it be that apple has devised a way of their own?

Vic Landi 

> From: "Bernard M. Piller" <[email-masked]>
> Organization: bmp System Support - keep your systems running
> Reply-To: [email-masked]
> Date: Thu, 29 Mar 2001 17:25:30 +0200
> To: [email-masked]
> Subject: Sherlock from Mac OS 9 slow
> Resent-From: [email-masked]
> Resent-Date: Thu, 29 Mar 2001 10:34:45 -0500 (EST)
> 
> Hi,
>

---

From: Lorenzo Perone <[email-masked]>
Date: Thu, 29 Mar 2001 23:04:55 +0200

>rasierfs (this I'm unsure of)

Hi!

I don't understand why a different filesystem should be needed.
I mean, _find_ works way faster than sherlock searches on netatalk - wouldn't it be possible to link to find or its library, or use its sources to implement a faster search?
I made some tests over a Perl CGI using find (plannig to make a sherlock plug-in with file:// urls), and though slower than sherlock-on-asip, it was very usable for what concerns the speed (on netatalk sherlock is unusable, let's face it - at least on volumes larger than 4GB).
Unfortunately, because my netatalk is not yet using codepages, I can't use this CGI yet (url / character conversion issues...).
If I get to finish it and it looks usable I can post that cgi here, but I'd prefer somebody could  implement something like find-in-netatalk......

:-)

Lorenzo

---

From: Vic Landi <[email-masked]>
Date: Thu, 29 Mar 2001 17:19:52 -0500

Problem is that _find_ is usually generated every night by cron... The mac
does it on the fly... if you wanted to repeat the process, you'd be choking
up a lot of time running the update every second...

Don't ask me about the file system thing... I'm just relating what I was
told the last time when I brought this up...

> From: Lorenzo Perone <[email-masked]>
> Date: Thu, 29 Mar 2001 23:04:55 +0200
> To: Vic Landi <[email-masked]>
> Cc: <[email-masked]>
> Subject: Re: Sherlock from Mac OS 9 slow
> Resent-Date: Thu, 29 Mar 2001 16:12:35 -0500 (EST)
> 
> I mean, _find_ works way faster than sherlock searches on netatalk - wouldn't
> it be possible to link to find or its library, or use its sources to implement
> a faster search?
> I made some tests over a Perl CGI using find (plannig to make a sherlock
> plug-in with file:// urls), and though slower than sherlock-on-asip, it was
> very usable for what concerns the speed (on netatalk sherlock is unusable,
> let's face it - at least on volumes larger than 4GB).
> Unfortunately, because my netatalk is not yet using codepages, I can't use
> this CGI yet (url / character conversion issues...).
> If I get to finish it and it looks usable I can post that cgi here, but I'd
> prefer somebody could  implement something like find-in-netatalk......
> 
> :-)
> 
> 
> Lorenzo
> 
>

---

From: Lorenzo Perone <[email-masked]>
Date: Fri, 30 Mar 2001 03:18:18 +0200

>up a lot of time running the update every second...

You seem to be right. /usr/bin/finding on 60gigs of hds took 10 mins 
14 secs.. (G3  DT/ 266)
while OS9 on a G4 needs _20 secs_ on the same amount of data.  It 
looks like some kind of index is being made 'on the fly'...
But: the same search that took 46 secs with find -iname, took _25_ 
minutes with netatalk to complete (for 625 result items in 16 Gigs). 
that can't be true.
Find is terribly slow but, still, usable - waiting for one 
neta-search to complete  you get old.
It would still be an improvement x30 to implement find's methods...

on the other hand, as for alternatives: i think a combination of 
apache (Options Indexes et al.), htdig and a sherlock-plug-in might 
do a good job for content-based finding, that could partially ease 
the pain of not having decent name searches. I still don't know what 
Sherlock does with a link like file:///folder/file.... he might as 
well try to open it with a browser  and for sure there'll be no 'Open 
Enclosed Folder' option available. So it might also involve writing a 
small 'Neta-htdig-Sherlock....' or an app handling a 'special 
protocol' like netatalk://. In this case one could search with a 
browser and the link would then reveal (via a special app catching 
the appropriate event) the file.... yes, it's getting tricky.

;-!

Lorenzo