Re: Perfomance problem backupscript (more details and tests)

Les Mikesell <[email protected]> wrote:

> > > The systems were running stock Sun software, and that is what was
> > > crashing.  I think Sun has become more sensible about providing
> > > software updates, but it's too late for me.
> > 
> > So you do not tell us the truth! I am still running a Sparcstation-II with
> > Solaris-2.4 and it is rock solid.
>
> 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....


> > 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 are you talkin about?

> 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.

On Linux a 32 bit process is still unable to execute arbitrary IOCTLs.
Solaris has a unified model to transform structures and addresses from
a 32 bit to the 64 bit kernel view, Linux does not.


> > > I was hoping you would fill in the details here about what amanda would
> > > have to do to know the tapes needed in this circumstance. It has been
> > 
> > I have no idea what your real objectives are...
>
> I thought I explained that clearly.  Amanda indexes files during

Why do you ask about things that have already been answered?



> > 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....


> > Star implements a different method that (in contrary to the GNU tar method)
> > has been verified to work reliably. Why do you like star to implement a method
> > that does yet have been verified to work at all?
>
> How many reasons would you like?  I'd like it because it is a practical
> and efficient method for backups.  I'd like it because it is possible
> to restore a renamed file with only the tape containing the name
> you know you want.  I'd like it because it permits arbitrary
> file exclusions with no restrictions on renaming.  I'd like it
> because it permits backups to cross mount points and mount points
> to change between runs without losing data. I'd like it because
> I think you can make it work.

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

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


> > At least you now admit that you don't use a released GNU tar version
> > but the current internal developer version of the source. As you tell us that
> > you like to get "stable" software, why do you use unreleased developer
> > versions of GNU tar?
>
> 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?

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

Jörg

-- 
 EMail:[email protected] (home) Jörg Schilling D-13353 Berlin
       [email protected]		(uni)  
       [email protected]	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily