Re: Perfomance problem backupscript (more details and tests)

On Fri, 2005-10-21 at 07:13, Joerg Schilling wrote:

> > Is it exposed to the internet and running the original stock sendmail
> > and dns server supplied with 2.4?  Can I have the IP address?
> 
> So you _really_ like to tell us that dns or sendmail prpblemd would have
> influence on the _stability_ of the OS? THis sounds funny....

You didn't reply about running those services on an internet exposed
machine, but I know the answer if the box is still up and those
programs have not been updated. Several root exploits have been fixed
since those versions.  I know that because I can see the changelogs of
sendmail and named.  I don't have access to the Solaris changelogs, but
I'd be fairly certain that memory leaks have been fixed since then.
Occasionally my boxes would spontaneously reboot but the more common
failure mode was to become completely unresponsive until someone did a
power cycle.  I didn't know the exact cause, but assumed memory
leakage.  If you have plenty of ram, reboot often, or don't do whatever
triggers the leak you might be fine - or if you have access to updates
since the 2.4 version release it may have been fixed.

> > > UNIX always had well defined ways to do things and Linux just ignores them.
> >
> > The kernel has gone it's own way to improve things and has had faster
> 
> THE KERNEL is sumething I would expect in the /kernel directory.

What a quaint convention. Did the Berkeley folks make that one up?

> What are you talkin about?

Speed and quality.  While I never attempted to run a web server on
the Sun boxes myself, in working with apache and mod_perl software
I saw plenty of evidence on mailing lists and at conventions that
in the 1996-2000 time frame at least, Linux performed much better
than solaris.

> > networking than Solaris for many years.  Solaris 10 is the first
> > thing to come close and even now only on 64-bit hardware:
> 
> Nonsense!
> 
> Solaris 7 (from 1997!) did introduce 64 bit support and did already support
> much more 64 bit features the the latest Linux Kernel.

I specified networking speed as measured in the link I included. All
earlier similar comparisons I've ever seen showed Linux far faster.
It was a concession to Sun that I mentioned the one version -and only-
version where they have finally caught up.  

> > > GNU tar incrementals are known not to work.
> >
> > You can describe conditions where a GNU tar restore will fail to
> > create some files. I can describe conditions where a star backup will
> > fail to save some files.  I don't see a big difference here.
> 
> I did! Just follow the instructions....

I provided instructions to recover the data correctly from the GNUtar
incremental (just move the conflicting file out of the way first).  I
don't see any instructions to recover a file renamed from an
excluded area from the star incremental - which will not contain
the data even if the file now appears in an included area.

> It does not make sense to discuss features of a program that could not yet
> verify that the basic idea is implementable at all.

The GNUtar technique is obviously implementable, considering that it has
been working for at least a decade and it puts the right files on the
tapes. It just has some quirks in the incremental restore side.

> Let us stay with a backup method that has been proven to work (like the one
> that is used by ufsdump or star).

I'd venture a guess that GNUtar is being used for much more data than
ufsdump or star. It's been a while since I watched the amanda mail list
but I know some large sites have used the amanda/GNUtar combination.

> > There is nothing 'unreleased' about RedHat/fedora source RPMs. They
> > are published, publicly available, and entire distributions have
> 
> Do you really fail to understand that there is a difference
> between showing other people your current workspace and publishing a 
> complete program out of these files?

Yes, I don't understand the point you are trying to make at all.  The
source RPMs published by RedHat and fedora are the ones ready for
real-world use. It includes the copy from the developer's workspace
plus bugfixes from testing and user reports.  The bugfixes patches
accumulate over time as the distribution is updated.  They often
find their way back to the developer's version if they didn't
originate there.

> When the GNU tar maintainer will eventually _officially_ release their
> code, it will definitely not be called GNU tar-1.15.1

Do you mean there will be a time when software development stops in
general or just for tar?  Why will that matter to anyone?  I expect
to see the same sort of development continue for a long time where
each version fixes some old bugs and introduces some new ones and
much real-world testing has to be done to sort them out.

-- 
  Les Mikesell
   [email protected]