> Well, as an ex-Auspex as well as ex-Legato employee I'd have to state
> that unless Auspex has done some work that I don't know about, going
> from the SP/FP *through* the HP to a DLT would be real performance
> lose.

As compared to what?  As compared to going out over the network??

> Or have you shoved the DLT into an SP slot?  If so, well, hmm...
> probably really *is* an index problem- after all, the HP<>FP<>SP path
> was never supposed to be *that* fast; it's too bad that Auspex and
> legato never got together to embed the backup hooks into the FP where
> they really should be.

As an Auspex customer, I'm glad they didn't do that.  It would be
wasted (for us) effort we (along with all other Auspex customers) would
have had to pay for.  We use Amanda, and I'd strongly resist going to a
commercial binary-only (and undocumented) backup package.

Of course, if Auspex did it right and then publicized their hooks, that
would be another story.  But Auspex is *atrocious* about publicizing
their APIs; look at /usr/auspex - it's _full_ of programs that do
things that have no documented API.  (The ones that bug me the most are
ax_loadvpar, which is incapable of getting its table from anywhere but
/etc/vpartab, and filesystem isolation, which there is not even a
command-line interface to - it's made available only in the form of a
few utilities that know how to isolate and deisolate, but insist on
doing other things too.)  I've traced a few of them, and it's fairly
clear they're just doing magic ioctls, but figuring out how to use them
would mean disassembling and uncompiling the code, and they have no
commitment to supporting that interface anyway.

Me, *I* want to see NetBSD drivers supporting the Auspex hardware.  Not
that I expect it. :-(

Growl.

(We thank you for putting up with this polemic.  We now return you to
your regularly scheduled..um..what _has_ been going on here recently?)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B