Re: [Amanda-users] Re: Linux and dump

2001-05-20 Thread Jason Thomas

On Sun, May 20, 2001 at 08:28:32AM -0400, Ray Shaw wrote:
> Well, at least now your bzip2 option will be l instead of I :)
j actually

-- 
Jason Thomas   Phone:  +61 2 6257 7111
System Administrator  -  UID 0 Fax:+61 2 6257 7311
tSA Consulting Group Pty. Ltd. Mobile: 0418 29 66 81
1 Hall Street Lyneham ACT 2602 http://www.topic.com.au/

 PGP signature


Re: [Amanda-users] Re: Linux and dump

2001-05-20 Thread Ray Shaw


On Sun, May 20, 2001 at 04:45:52PM +1000, Jason Thomas wrote:
> On Fri, May 18, 2001 at 12:18:30AM -0400, Ray Shaw wrote:
> > 
> > On Thu, May 17, 2001 at 09:53:59PM -0300, Alexandre Oliva wrote:
> > 
> > > I can also tell from personal experience that I haven't had trouble
> > > with GNU tar 1.13.17 on GNU/Linux/x86, but I still haven't been able
> > > to do backups reliably with 1.13.19 (it will generally abort part-way
> > > through the back-up; I suspect a network problem, but a bug in GNU tar
> > > still isn't ruled out)
> > 
> > My systems (Debian potato):
> > 
> > media:~$ tar --version
> > tar (GNU tar) 1.13.17
> > 
> > media:~$ gcc --version
> > 2.95.2
> > 
> > No problems here, except that the kernel isn't best friends with my
> > ATA tape drive sometimes.  The joys of an academic budget! :)
> 
> when you say no problems have you tested using amverify.

No, but I've tried restoring random files from tapes.  And I've also
had to do some actual restores when another server went down (couldn't
simply move the disk over thanks to cursed proprietary CompaQ SCSI
disk interface...)

> I'm running the debian potato, and tar does not seem todo the right
> thing, the archives are corrupt.  I'm about to start testing with a
> newer version of tar taken from sid most probably.

Well, at least now your bzip2 option will be l instead of I :)


-- 
--Ray

-
Sotto la panca la capra crepa
sopra la panca la capra campa



Re: Linux and dump

2001-05-20 Thread Alexandre Oliva

On May 17, 2001, "John R. Jackson" <[EMAIL PROTECTED]> wrote:

>>> Looks like gcc 2.8.1.

>> Gee.  That's dead broken.  ...

> Yeah, yeah.  But you're just a wee bit biased :-) :-).

FYI, I've just found this in GNU tar 1.13.19's README:


* Solaris issues.

GNU tar exercises many features that can cause problems with older GCC
versions.  In particular, GCC 2.8.1 (sparc, -O1 or -O2) is known to
miscompile GNU tar.  No compiler-related problems have been reported
when using GCC 2.95.2 or later.



And here's the patch for a crash I had mentioned I had found.  It
would crash while doing --listed-incremental full or incremental
backups whenever it didn't have permission to enter a directory:



--- src/incremen.c~	Sat Jan 13 03:59:29 2001
+++ src/incremen.c	Sun May 20 05:51:37 2001
@@ -183,7 +183,10 @@
 enum children children;
 
 if (! dirp)
-  savedir_error (path);
+  {
+	savedir_error (path);
+	return 0;
+  }
 errno = 0;
 
 name_buffer_size = strlen (path) + NAME_FIELD_SIZE;



-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me



Re: [Amanda-users] Re: Linux and dump

2001-05-19 Thread Jason Thomas

On Fri, May 18, 2001 at 12:18:30AM -0400, Ray Shaw wrote:
> 
> On Thu, May 17, 2001 at 09:53:59PM -0300, Alexandre Oliva wrote:
> 
> > I can also tell from personal experience that I haven't had trouble
> > with GNU tar 1.13.17 on GNU/Linux/x86, but I still haven't been able
> > to do backups reliably with 1.13.19 (it will generally abort part-way
> > through the back-up; I suspect a network problem, but a bug in GNU tar
> > still isn't ruled out)
> 
> My systems (Debian potato):
> 
> media:~$ tar --version
> tar (GNU tar) 1.13.17
> 
> media:~$ gcc --version
> 2.95.2
> 
> No problems here, except that the kernel isn't best friends with my
> ATA tape drive sometimes.  The joys of an academic budget! :)

when you say no problems have you tested using amverify.

I'm running the debian potato, and tar does not seem todo the right
thing, the archives are corrupt.  I'm about to start testing with a
newer version of tar taken from sid most probably.

> 
> I've never tried amanda on anything but Linux, so I can't speak about
> that.  sunfreeware.com might have a good version of gcc.
> 
> 
> -- 
> --Ray
> 
> -
> Sotto la panca la capra crepa
> sopra la panca la capra campa
> 
> 
> ___
> amanda-users mailing list
> [EMAIL PROTECTED]
> http://mail.topic.com.au/cgi-bin/mailman/listinfo/amanda-users

-- 
Jason Thomas   Phone:  +61 2 6257 7111
System Administrator  -  UID 0 Fax:+61 2 6257 7311
tSA Consulting Group Pty. Ltd. Mobile: 0418 29 66 81
1 Hall Street Lyneham ACT 2602 http://www.topic.com.au/

 PGP signature


Re: Linux and dump

2001-05-19 Thread Mitch Collinsworth



On Fri, 18 May 2001, Bernhard R. Erdmann wrote:

> Did you read http://reality.sgi.com/zwicky_neu/testdump.doc.html ?
> (Elizabeth D. Zwicky, Torture-testing Backup and Archive Programs:
> Things You Ought to Know But Probably Would Rather Not)
> 
> Dump rocks!
 

An interesting read, however it's 10 years old.  I have to wonder
how much has changed in the intervening time.  It could be
interesting to re-run the test suite using modern tools.

-Mitch




Re: Linux and dump

2001-05-18 Thread Dan Wilder

On Fri, May 18, 2001 at 11:43:01AM -0500, John R. Jackson wrote:
> >I was never able to compile GNU tar with gcc 2.8.1 on Solaris.
> >But I work fine if compiled with SUN cc.
> 
> I retried my test case using GNU tar 1.13.19 built with Sun cc and
> with gcc-2.95.3.  Both work fine.  So it was a bug with 2.8.1.

I don't know what the official word is on gcc, but I can report
my own results.  

I've been building and using gcc in various native and cross 
configurations since early gcc-2.3 (built on a 386-16 with
4M of RAM, it took all night to build) and the versions I've
had the best luck with are gcc-2.7.2.1 through 2.7.2.3, and
2.95.3.  2.95.2 was very good, too, but it won't handle some
of the recent c++ code I need it to build.

Some of the egcs versions worked pretty well for me, too, but
egcs is officially deprecated, as I understand it, in favor of 
gcc-2.95.

> As Dan Wilder said, the important point is that you can never do 
> enough backup/restore testing, no matter what [archiving utility] 
> you use.

Thanks, John, for emphasizing that.  I believe the point is too
often neglected.

A correlary: not testing at all is never sufficient.  Even a little 
bit of testing is a whole lot better than none, but there are gains to
be had from even more testing.

One thing I always do in my amanda run scripts, is give
"amverify" a crack at the tape, with the result emailed to me.

The extra wear and tear on tape and tape drive seems more than 
justified by the confirmation that the darned thing was read 
back successfully, at least once, for every backup.

-- 
Dan Wilder



Re: Linux and dump

2001-05-18 Thread John R. Jackson

>I was never able to compile GNU tar with gcc 2.8.1 on Solaris.
>But I work fine if compiled with SUN cc.

I retried my test case using GNU tar 1.13.19 built with Sun cc and
with gcc-2.95.3.  Both work fine.  So it was a bug with 2.8.1.

I didn't say it very well in the original post, but I was not trying to
knock GNU tar (well, maybe just a little :-).  As Dan Wilder said, the
important point is that you can never do enough backup/restore testing,
no matter what you use.

Thanks to all for the compiler tip.  I would have spent quite a bit of
time digging through GNU tar hunting that down.

>Jean-Louis

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]



Re: Linux and dump

2001-05-18 Thread Gerhard den Hollander

* John R. Jackson <[EMAIL PROTECTED]> (Thu, May 17, 2001 at 04:02:19PM -0500)
> I was going to stay out of yet another round of "dump vs tar", but what
> the hell.  Here's a little eye-opener for all you tar folks ...

>   $ gtar --version
>   tar (GNU tar) 1.13.19

> Not to panic you or anything, of course.  Have a nice day.  :-)

As more people have shown, if you have compiled gnutar with Suns cc
compiler (usually a piece of crap, but in this case it works ;) ) gnutar
works fine.

For those who need a version of gnutar (Sol 2.6 or better, will likely not
work on 2.5.1 or earlier) I've uploaded my copy to

http://gdenhollander.cjb.net/gnutar.1.13.19

Currently listening to:  David Gilmour - In Concert (VCD)

Gerhard,  <@jasongeo.com>   == The Acoustic Motorbiker ==   
-- 
   __O  Some say the end is near.
 =`\<,  Some say we'll see armageddon soon
(=)/(=) I certainly hope we will
I could use a vacation




Re: Linux and dump

2001-05-17 Thread Ray Shaw


On Thu, May 17, 2001 at 09:53:59PM -0300, Alexandre Oliva wrote:

> I can also tell from personal experience that I haven't had trouble
> with GNU tar 1.13.17 on GNU/Linux/x86, but I still haven't been able
> to do backups reliably with 1.13.19 (it will generally abort part-way
> through the back-up; I suspect a network problem, but a bug in GNU tar
> still isn't ruled out)

My systems (Debian potato):

media:~$ tar --version
tar (GNU tar) 1.13.17

media:~$ gcc --version
2.95.2

No problems here, except that the kernel isn't best friends with my
ATA tape drive sometimes.  The joys of an academic budget! :)

I've never tried amanda on anything but Linux, so I can't speak about
that.  sunfreeware.com might have a good version of gcc.


-- 
--Ray

-
Sotto la panca la capra crepa
sopra la panca la capra campa



Re: Linux and dump

2001-05-17 Thread Alexandre Oliva

On May 17, 2001, "John R. Jackson" <[EMAIL PROTECTED]> wrote:

>> Do you know which compiler was used to build this version of GNU tar?

> Looks like gcc 2.8.1.

Gee.  That's dead broken.  First thing I'd do would be to get GNU tar
1.13.19 built with a newer compiler.  But I can tell from personal
experience that, even when built with GCC 2.95.3, on Solaris 7/x86, it
wouldn't even be able to do estimates properly.  So I stayed with 1.12
for now.  Investigating the actual problem is in my to-do list.

I can also tell from personal experience that I haven't had trouble
with GNU tar 1.13.17 on GNU/Linux/x86, but I still haven't been able
to do backups reliably with 1.13.19 (it will generally abort part-way
through the back-up; I suspect a network problem, but a bug in GNU tar
still isn't ruled out)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me



Re: Linux and dump

2001-05-17 Thread Jean-Louis Martineau

On Thu, May 17, 2001 at 05:15:00PM -0500, John R. Jackson wrote:
> >Do you know which compiler was used to build this version of GNU tar?
> 
> Looks like gcc 2.8.1.

I was never able to compile GNU tar with gcc 2.8.1 on Solaris.
But I work fine if compiled with SUN cc.

Jean-Louis
-- 
Jean-Louis Martineau email: [EMAIL PROTECTED] 
Departement IRO, Universite de Montreal
C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529
Montreal, Canada, H3C 3J7Fax: (514) 343-5834



Re: Linux and dump

2001-05-17 Thread John R. Jackson

> Did you try to read this tar-file with some other tar program?  ...
>... such as GNU tar 1.12?

Same result.

>> Looks like gcc 2.8.1.

>Gee.  That's dead broken.  ...

Yeah, yeah.  But you're just a wee bit biased :-) :-).

>First thing I'd do would be to get GNU tar
>1.13.19 built with a newer compiler.  ...

So what's the recommended **stable** gcc these days?  I'll try to scrounge
up the 100+ MBytes and CPU hours it takes to build and give that a try.

>Alexandre Oliva

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]



Re: Linux and dump

2001-05-17 Thread Dan Wilder

On Thu, May 17, 2001 at 06:36:16PM -0300, Alexandre Oliva wrote:
> On May 17, 2001, Dan Wilder <[EMAIL PROTECTED]> wrote:
> 
> > Is this an option amrecover can (or does) pass to tar?
> 
> Nope.  amrecover explicitly tells tar which files to restore, so this
> is not an issue.
> 

Ahh.  Good!  

Amrecover is such a great tool for restoring files, a few or a whole 
filesystem full. I have a hard time imagining a circumstance that 
would lead me to going directly to the underlying archive utility.  
For restoring from Amanda tapes, that is.  Be that underlying utiility 
dump, xfsdump, tar, or what not.

-- 
Dan Wilder



Re: Linux and dump

2001-05-17 Thread Dan Wilder

On Thu, May 17, 2001 at 04:02:19PM -0500, John R. Jackson wrote:

> But if'n I were you folks using this version of GNU tar, I'd start
> making damn sure your tapes had anything even faintly useful on them.
> Amverify should do the trick, although I certainly wouldn't stop there.
> 
> Not to panic you or anything, of course.  Have a nice day.  :-)

Hee, hee!

Yeah, conservative is better in backup utilities.  I've doggedly
installed GNU tar 1.12 plus amanda patches in every system I've been 
responsible for.  Restored lots of files.  Never lost one.

One key point is test, test, test.  Don't ever assume
backup is working, especially if you've changed anything.  Do
some random restores even if you don't have to.  Fuss over them.
Look at 'em with a fine-tooth comb. 

I believe this is much more important to safe and successful
backups than your choice of archiving utility.  Plus, if you make
a wrong choice, this is your chance to find out!

-- 
Dan Wilder



Re: Linux and dump

2001-05-17 Thread Alexandre Oliva

On May 17, 2001, "John R. Jackson" <[EMAIL PROTECTED]> wrote:

>> Did you try to read this tar-file with some other tar program?  ...

... such as GNU tar 1.12?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me



Re: Linux and dump

2001-05-17 Thread Alexandre Oliva

On May 17, 2001, "John R. Jackson" <[EMAIL PROTECTED]> wrote:

> Yeah, yeah.  But you're just a wee bit biased :-) :-).

Me!  No way!  :-D

>> First thing I'd do would be to get GNU tar
>> 1.13.19 built with a newer compiler.  ...

> So what's the recommended **stable** gcc these days?

2.95.3

> I'll try to scrounge up the 100+ MBytes and CPU hours it takes to
> build and give that a try.

I could build GNU tar 1.13.19 for you, to run on Solaris 2.6/sparc, if
that would help.  Just let me know.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me



Re: Linux and dump

2001-05-17 Thread Bernhard R. Erdmann

> Summary: "Dump was a stupid program in the first place. Leave it behind."

Did you read http://reality.sgi.com/zwicky_neu/testdump.doc.html ?
(Elizabeth D. Zwicky, Torture-testing Backup and Archive Programs:
Things You Ought to Know But Probably Would Rather Not)

Dump rocks!



Re: Linux and dump

2001-05-17 Thread John R. Jackson

>Just to make sure (and for the enlightenment of anyone else trying to
>duplicate the problem): you have removed /tmp/jrj/zli before every tar
>command, right?  ...

Yes.  What I posted was really the list of commands I put into a little
test script.  The cp of /dev/null to zli is part of that and happens on
each run.

>'cause I can't seem to be able to duplicate this
>problem on my machines.  ...

That also doesn't surprise me.  By now this mailing list would have been
flooded with "why is Amanda broken" letters :-) if it was universal.

Not that that should make anyone feel warm and fuzzy about what *their*
GNU tar is doing.

>Do you know which compiler was used to build this version of GNU tar?

Looks like gcc 2.8.1.

>Did you try to read this tar-file with some other tar program?  ...

Using Solaris tar (not exactly known for its stellar quality, either):

  $ tar tvf z.tar 
  drwxr-xr-x 10281/1233  62 Jun  8 13:53 1999 07301033644/./
  -rwxr-xr-x 10281/1233   10412 Jun  8 13:53 1999 07277623352/./getMailHostName
  -rw-r--r-- 10281/1233   15044 Jun  7 18:16 1999 07277623352/./res_init.c

No complaints, but it also didn't show all four files, just the first
two (and with bogus names, but that's just Solaris tar being stupid).

AIX tar did the same thing (two files) but without the bogus directory
name.

On a whim, I changed the test to write to a pipe to cat instead of
directing stdout to the file since I know GNU tar looks at what it's
writing to (e.g. so it can detect /dev/null).  Didn't help.

I also tried writing direcly via --file instead of "--file -".  Ditto.

>Alexandre Oliva

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]



Re: Linux and dump

2001-05-17 Thread Alexandre Oliva

On May 17, 2001, "John R. Jackson" <[EMAIL PROTECTED]> wrote:

>  --listed-incremental /tmp/jrj/zli \

> This does what Amanda does for a full dump.

Just to make sure (and for the enlightenment of anyone else trying to
duplicate the problem): you have removed /tmp/jrj/zli before every tar
command, right?  'cause I can't seem to be able to duplicate this
problem on my machines.  Do you know which compiler was used to build
this version of GNU tar?

>   $ gtar tvf z.tar
>   drwxr-xr-x jrj/pucc 62 1999-06-08 13:53:30 ./
>   -rwxr-xr-x jrj/pucc  10412 1999-06-08 13:53:30 ./getMailHostName
>   gtar: Unexpected EOF in archive
>   gtar: Error is not recoverable: exiting now

Did you try to read this tar-file with some other tar program?  Hmm, I
guess this doesn't matter much; it's pretty obvious tar didn't write
everything out to the tarball, given how small it is.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me



Re: Linux and dump

2001-05-17 Thread Alexandre Oliva

On May 17, 2001, Dan Wilder <[EMAIL PROTECTED]> wrote:

> Is this an option amrecover can (or does) pass to tar?

Nope.  amrecover explicitly tells tar which files to restore, so this
is not an issue.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me



Re: Linux and dump

2001-05-17 Thread Alexandre Oliva

On May 17, 2001, "John R. Jackson" <[EMAIL PROTECTED]> wrote:

> Oh, shit.

I wouldn't have put it better :-)

> I tried GNU tar 1.12 (plus the Amanda patches) and it works fine.

Thanks God I'm still using that one, on most systems I've got.  Talk
`conservative' regarding backups.

> But if'n I were you folks using this version of GNU tar, I'd start
> making damn sure your tapes had anything even faintly useful on them.

This is good advice, regardless of the backup tool you're using.

> Not to panic you or anything, of course.  Have a nice day.  :-)

:-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me



Re: Linux and dump

2001-05-17 Thread John R. Jackson

I was going to stay out of yet another round of "dump vs tar", but what
the hell.  Here's a little eye-opener for all you tar folks ...

  $ (umask 077 ; mkdir /tmp/jrj)
  $ cd /tmp/jrj
  $ rm z.tar zli
  $ cp /dev/null zli
  $ gtar --version
  tar (GNU tar) 1.13.19
  ...
  $ uname -srp
  SunOS 5.6 sparc
  $ gtar --create \
 --file - \
 --directory /work/tmp/resolv \
 --one-file-system \
 --listed-incremental /tmp/jrj/zli \
 --sparse \
 --ignore-failed-read \
 --totals \
 . > z.tar

This does what Amanda does for a full dump.  It creates an empty listed
incremental file then does the deed.  The /work/tmp/resolv directory has
four files in it and was just a random choice of something to test with:

  $ ls -lR /work/tmp/resolv
  /work/tmp/resolv:
  total 82
  -rwxr-xr-x   1 jrj  pucc   10412 Jun  8  1999 getMailHostName
  -rw-r--r--   1 jrj  pucc3028 Jun  8  1999 getMailHostName.c
  -rw-r--r--   1 jrj  pucc   15044 Jun  7  1999 res_init.c
  -rw-r--r--   1 jrj  pucc   12170 Jun  7  1999 res_query.c

Here's the output of the gtar --create:

  Total bytes written: 10240 (10kB, 791kB/s)

Fine.  Everything's hunky, dory.  Hmmm, how about we do a "tar t" on
that:

  $ gtar tvf z.tar
  drwxr-xr-x jrj/pucc 62 1999-06-08 13:53:30 ./
  -rwxr-xr-x jrj/pucc  10412 1999-06-08 13:53:30 ./getMailHostName
  gtar: Unexpected EOF in archive
  gtar: Error is not recoverable: exiting now

Oh, shit.

I've tried this on several directories.  They all fail.  GNU tar (1.13.19)
is broken, at least on my Solaris box.  And because GNU tar didn't say
squat about any problems, you'd never know it happened unless you looked
really closely at the E-mail output (e.g. the dump size is too small),
or tried to do an amrecover (the file list would be wrong because the
"tar t" it runs would have failed) or a real restore.

I tried GNU tar 1.12 (plus the Amanda patches) and it works fine.

>You've been lucky for years.  Some day, [dump will] bite you, and you'll
>regretfully remember this discussion.  ...
>So your point is that dump should refuse to run on a mounted
>filesystem?  Yeah, that sounds reasonable to me.  Then more people
>would learn about its limitations and switch to some saner backup
>tool.

And which tool would that be?  :-)

I just found this problem a couple of days ago (while looking into
George Herson's problem) and haven't had time to start tracking it down
or report it.

But if'n I were you folks using this version of GNU tar, I'd start
making damn sure your tapes had anything even faintly useful on them.
Amverify should do the trick, although I certainly wouldn't stop there.

Not to panic you or anything, of course.  Have a nice day.  :-)

>Alexandre Oliva

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]



Re: Linux and dump

2001-05-17 Thread Jonathan Dill

I think I was the one who made the suggestion to remove ext2 dump, but I
was wrong, you don't have to do that.  ./configure will find both
xfsdump and dump, and amanda will choose whichever program is
appropriate for the type of filesystem i.e. if it is XFS filesystem and
you have not specified GNUTAR, xfsdump will be used automatically.

Alexandre Oliva wrote:
> On May 17, 2001, "C. Chan" <[EMAIL PROTECTED]> wrote:
> 
> > I followed suggestions to remove ext2 dump so
> > Amanda would detect xfsdump and recompiled, but I find this rather inelegant.
> 
> What is inelegant?  Removing ext2 dump?  You didn't have to do that.
> You only need xfsdump available at configure time to get the xfsdump
> supporting bits enabled; the existence of ext2 dump doesn't make a
> difference.

-- 
"Jonathan F. Dill" ([EMAIL PROTECTED])
CARB Systems and Network Administrator
Home Page:  http://www.umbi.umd.edu/~dill



Re: Linux and dump

2001-05-17 Thread Dan Wilder

On Thu, May 17, 2001 at 05:09:16PM -0300, Alexandre Oliva wrote:
> On May 17, 2001, Ron Stanonik <[EMAIL PROTECTED]> wrote:
> 
> > Sorry for the newbie question, but how can tar be configured so
> > that after restoring a full and an incremental the filesystem has
> > exactly the files at the time of the incremental, not any files
> > which were present during the full but removed before the incremental.
> 
> Use -G at restore time.  From the GNU tar manual:
> 
>`--incremental' (`-G') in conjunction with `--extract' (`--get',
> `-x') causes `tar' to read the lists of directory contents previously
> stored in the archive, _delete_ files in the file system that did not
> exist in their directories when the archive was created, and then
> extract the files in the archive.
> 
>This behavior is convenient when restoring a damaged file system from
> a succession of incremental backups: it restores the entire state of
> the file system to that which obtained when the backup was made.  If
> `--incremental' (`-G') isn't specified, the file system will probably
> fill up with files that shouldn't exist any more.

Is this an option amrecover can (or does) pass to tar?

Thanks, by the way, for the words to the wise on "dump".  

-- 
-
 Dan Wilder <[EMAIL PROTECTED]>   Technical Manager & Editor
 SSC, Inc. P.O. Box 55549   Phone:  206-782-8808
 Seattle, WA  98155-0549URL http://embedded.linuxjournal.com/
-



Re: Linux and dump

2001-05-17 Thread Alexandre Oliva

On May 17, 2001, "Anthony A. D. Talltree" <[EMAIL PROTECTED]> wrote:

>> But this is not a problem of linux, it's a problem of dump.

> Yeah yeah yeah.  We've all heard that a million times before, and yet on
> real systems we've been happily using dump for years without
> consequences.

You've been lucky for years.  Some day, it'll bite you, and you'll
regretfully remember this discussion.  Or perhaps you'll keep on being
lucky.

Good luck :-)

> A more fitting analogy would be GM making cars out of cardboard and
> warning people to not leave them out in the sun because they might catch
> fire.

So your point is that dump should refuse to run on a mounted
filesystem?  Yeah, that sounds reasonable to me.  Then more people
would learn about its limitations and switch to some saner backup
tool.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me



Re: Linux and dump

2001-05-17 Thread Alexandre Oliva

On May 17, 2001, "C. Chan" <[EMAIL PROTECTED]> wrote:

> I followed suggestions to remove ext2 dump so
> Amanda would detect xfsdump and recompiled, but I find this rather inelegant.

What is inelegant?  Removing ext2 dump?  You didn't have to do that.
You only need xfsdump available at configure time to get the xfsdump
supporting bits enabled; the existence of ext2 dump doesn't make a
difference.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me



Re: Linux and dump

2001-05-17 Thread Alexandre Oliva

On May 17, 2001, Ron Stanonik <[EMAIL PROTECTED]> wrote:

> Sorry for the newbie question, but how can tar be configured so
> that after restoring a full and an incremental the filesystem has
> exactly the files at the time of the incremental, not any files
> which were present during the full but removed before the incremental.

Use -G at restore time.  From the GNU tar manual:

   `--incremental' (`-G') in conjunction with `--extract' (`--get',
`-x') causes `tar' to read the lists of directory contents previously
stored in the archive, _delete_ files in the file system that did not
exist in their directories when the archive was created, and then
extract the files in the archive.

   This behavior is convenient when restoring a damaged file system from
a succession of incremental backups: it restores the entire state of
the file system to that which obtained when the backup was made.  If
`--incremental' (`-G') isn't specified, the file system will probably
fill up with files that shouldn't exist any more.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me



Re: Linux and dump

2001-05-17 Thread Ron Stanonik

Sorry for the newbie question, but how can tar be configured so
that after restoring a full and an incremental the filesystem has
exactly the files at the time of the incremental, not any files
which were present during the full but removed before the incremental.

Thanks,

Ron Stanonik
[EMAIL PROTECTED]




Re: Linux and dump

2001-05-17 Thread Joshua Baker-LePain

On Thu, 17 May 2001 at 8:50am, Anthony A. D. Talltree wrote

> >Yikes!  A troll!
>
> Nope, just a naked emperor.

This Needs To Stop.  Now.  I have had enough of anti-Linux flamefests, and
I especially do not want to see one on a mailing list with one of the
hightest SNRs I've ever seen.

If you want to continue this with anybody (and no, I am not interested)
take it off list.

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University





Re: Linux and dump

2001-05-17 Thread Joshua Baker-LePain

On Thu, 17 May 2001 at 11:09am, C. Chan wrote

> I made some backups with Amanda using GNU tar and xfsdump and the recovery
> under both was consistent. I followed suggestions to remove ext2 dump so
> Amanda would detect xfsdump and recompiled, but I find this rather inelegant.
> I plan to make a JFS partition as well, so this machine will
> have multiple dumps, and I'd like to be able to specify which dump to
> use for a filesystem in my amanda.conf file.
>
As John R. Jackson has pointed out, amanda "should" discover fs type and
use the proper dump program (given that it was detected at configure
time).  Multiple filesystems on one box should not be a problem.  If they
are, it's a bug and should be reported as such.

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University




Re: Linux and dump

2001-05-17 Thread C. Chan

Also Sprach Anthony A. D. Talltree:

> >Yikes!  A troll!
>   
> Nope, just a naked emperor.
> 

No, a nakked emperor penguin.

--
C. Chan < [EMAIL PROTECTED] > 
Finger [EMAIL PROTECTED] for PGP public key.




Re: Linux and dump

2001-05-17 Thread C. Chan

Also Sprach Dan Wilder:

> On Thu, May 17, 2001 at 07:51:09AM -0700, Anthony A. D. Talltree wrote:
> > >Summary: "Dump was a stupid program in the first place. Leave it behind."
> > 
> > What it really means:  "Linux is a toy system and rather than fix our
> > design flaws we'll play sour grapes."
> > 
> 
> Yikes!  A troll!
> 

(Well, this stuff isn't all that related to Amanda but...)

*Shrug*. Troll or not, the fact is that some of us have to work with
Linux systems and get them backed up. And to be honest XFS support
is a big factor in choosing Linux over other free OSes like *BSD because now
we don't have to format ~TB worth of IRIX disk when moving them to a new
platform. Linux may have not be close to IRIX in terms of stability or
scalability but the siren song of commodity PC hardware vitiates all logic.

I am not certain whether Torvalds was referring to ext2 dump or block
level backup in general. The decision to use the page cache rather than
buffer cache may be different from what BSD or SysV have done, but I don't
think it is totally without merit. In exchange for greater difficulties in
writing utilities like dump, there is the supposed advantage of simplifying
the filesystem programming API and so on. Also SGI's port (albeit with
numerous patches) of XFS and presumably the IBM JFS port demonstrate that
you can have a dump-like util for journaled filesystems under Linux.

As for my XFS progress on Linux:

I downloaded the SGI patched 2.4.3 kernel and utils and installed it on
a box running a Mandrake 8.0 installation. I also had to grab the
updated quota-utils from SourceForge. I made an XFS filesystem, copied
over some stuff, started some r/w to files, did the power on/off and it seemed
to recover properly.

I applied quotas and went over quota and the behavior was as expected.

I made some backups with Amanda using GNU tar and xfsdump and the recovery
under both was consistent. I followed suggestions to remove ext2 dump so
Amanda would detect xfsdump and recompiled, but I find this rather inelegant.
I plan to make a JFS partition as well, so this machine will
have multiple dumps, and I'd like to be able to specify which dump to
use for a filesystem in my amanda.conf file.

--
C. Chan < [EMAIL PROTECTED] > 
Finger [EMAIL PROTECTED] for PGP public key.




Re: Linux and dump

2001-05-17 Thread Anthony A. D. Talltree


>Dump bypasses the filesystemlevel to access the data and therefor only
>works reliable if all caches are flushed to disk. This is only garanteed 
>if the filesystem is unmounted or at least mounted read-only.

Yes, I know.  I learned that 15 years ago.

>But this is not a problem of linux, it's a problem of dump.

Yeah yeah yeah.  We've all heard that a million times before, and yet on
real systems we've been happily using dump for years without
consequences.

>what you are saying is the same as if you try to change a wheel 
>of your car without making shure it won't roll away while working,
>and when it rolls away an breaks your foot saying "what a damn bad
>car..."

A more fitting analogy would be GM making cars out of cardboard and
warning people to not leave them out in the sun because they might catch
fire.



Re: Linux and dump

2001-05-17 Thread Christoph Scheeder



"Anthony A. D. Talltree" schrieb:
> 
> >Summary: "Dump was a stupid program in the first place. Leave it behind."
> 
> What it really means:  "Linux is a toy system and rather than fix our
> design flaws we'll play sour grapes."

wrong. 
what it realy means is: dont use a loaded rifle as a walkingstick, 
you might shoot your foot.

dump is ok with linux if you use it on an unmounted filesystem.
everything other is abuse.
Dump bypasses the filesystemlevel to access the data and therefor only
works reliable if all caches are flushed to disk. This is only garanteed 
if the filesystem is unmounted or at least mounted read-only.

But this is not a problem of linux, it's a problem of dump.

what you are saying is the same as if you try to change a wheel 
of your car without making shure it won't roll away while working,
and when it rolls away an breaks your foot saying "what a damn bad
car..."
Christoph



Re: Linux and dump

2001-05-17 Thread Anthony A. D. Talltree

>Yikes!  A troll!

Nope, just a naked emperor.




Re: Linux and dump

2001-05-17 Thread Dan Wilder

On Thu, May 17, 2001 at 07:51:09AM -0700, Anthony A. D. Talltree wrote:
> >Summary: "Dump was a stupid program in the first place. Leave it behind."
> 
> What it really means:  "Linux is a toy system and rather than fix our
> design flaws we'll play sour grapes."
> 

Yikes!  A troll!

-- 
-
 Dan Wilder <[EMAIL PROTECTED]>   Technical Manager & Editor
 SSC, Inc. P.O. Box 55549   Phone:  206-782-8808
 Seattle, WA  98155-0549URL http://embedded.linuxjournal.com/
-



Re: Linux and dump

2001-05-17 Thread Anthony A. D. Talltree

>Summary: "Dump was a stupid program in the first place. Leave it behind."

What it really means:  "Linux is a toy system and rather than fix our
design flaws we'll play sour grapes."



Re: Linux and dump

2001-05-17 Thread Harri Haataja

On Thu, 17 May 2001, Jonathan Dill wrote:

> I'm planning to migrate to SGI XFS on Linux--SGI has released an
> installer CD for Red Hat 7.1 which can make XFS filesystems.  XFS is a
> journaled filesystem, and it can be run over RAID unlike ext3 which had
> problems with RAID on 2.2 kernel.  You can download the installer for
> free from ftp://linux-xfs.sgi.com but the server appears to be down
> right now.

I'll drop a few lines on this.

The graphical cdrom installer works just nice, but I usually do my
installs from an http server set up for that. Trying the netboot floppy on
the CD and expert mode (allows selecting media) IIRC let me use the
network install but *do not have RAID creation* in them. The graphic cdrom
install lets me have RAID (very easy) but not network install =).

I don't know if this makes a difference and it's definately not
amanda-specific, but thought I'd mail it.

If only it let me define pv's and LVM at the same time =)

-- 
"It's seems to be spreading faster as Anna Kournikova"
-- Mikko Hyyppönen on VBSWG.X (fsecure.com)





Re: Linux and dump

2001-05-17 Thread Jonathan Dill

Hi Eric,

You may want to take a look through the list archives at:

http://groups.yahoo.com/group/amanda-users/

This subject has already been hashed and rehashed to death on just about
every mailing list that I subscribe to including this one.

I'm planning to migrate to SGI XFS on Linux--SGI has released an
installer CD for Red Hat 7.1 which can make XFS filesystems.  XFS is a
journaled filesystem, and it can be run over RAID unlike ext3 which had
problems with RAID on 2.2 kernel.  You can download the installer for
free from ftp://linux-xfs.sgi.com but the server appears to be down
right now.

Eric Veldhuyzen wrote:
> I just saw that someone had problems with dump and Linux. This made
> me remember an posting from Linux Torvalds of a few weeks back which I
> think anyone still using dump with Linux should read:
> 
>http://www.lwn.net/2001/0503/a/lt-dump.php3
> 
> Summary: "Dump was a stupid program in the first place. Leave it behind."

-- 
"Jonathan F. Dill" ([EMAIL PROTECTED])



Linux and dump

2001-05-17 Thread Eric Veldhuyzen

Hi,

I just saw that someone had problems with dump and Linux. This made
me remember an posting from Linux Torvalds of a few weeks back which I
think anyone still using dump with Linux should read:

   http://www.lwn.net/2001/0503/a/lt-dump.php3

Summary: "Dump was a stupid program in the first place. Leave it behind."

-- 
#!perl #   Life ain't fair, but root passwords help.
# Eric Veldhuyzen  [EMAIL PROTECTED]
$!=$;=$_+(++$_);($:,$~,$/,$^,$*,$@)=$!=~   # Perl Monger
/.(.)...(.)(.)(.)..(.)..(.)/;`$^$~$/$: $^$*$@$~ $_>&$;`