Re: [Amanda-users] Re: Linux and dump
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: clip 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
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:
quote
* 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.
/quote
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
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: clip 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
* 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
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
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
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])
Re: Linux and dump
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
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
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
Yikes! A troll! Nope, just a naked emperor.
Re: Linux and dump
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
On Thu, May 17, 2001 at 09:53:59PM -0300, Alexandre Oliva wrote: clip 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
