dump-devel

Re: [Dump-devel] Patch to add MB output to dump

[Stelian P. <st...@ca...>]

On Tue, 7 Mar 2000, International Man of Mystery wrote:

> 
> This patch makes dump report the MB of records dumped.  While it's
> somewhat redundant, it's easier for scripts to search for \((.+)MB\) and
> it's what Solaris' ufsdump does, so report scripts can have a little less
> logic.
> 

Thanks for your patch. I've included it (with some small
modifications) in the CVS, so it will be in the next version.

Stelian.
-- 
Stelian Pop <sp...@ca...>| Too many things happened today
Captimark                      | Too many words I don't wanna say
Paris, France                  | I wanna be cool but the heat's coming up
                               | I'm ready to kill 'cause enough is enough
PGP key available on request   |              (Accept - "Up To The Limit")

[Dump-devel] filenames from file for restore

[Dejan M. <de...@qu...>]

Hello,

I wrote a small script to assist my Mac users to recover files from
dumps.  However, they are going wild when giving names to files (all 
kind of funny stuff).  I've found this to be almost impossible to handle
with a shell script.  So, here's a small update to restore(8) which
extends its functionality so that a list of files to be extracted/listed
comes from a named file (like '-T' option for gnutar).  I've chosen '-X'
option for this.  stdin is not supported because I was not sure how to
handle the following case

# restore -tf - -X -

Hope you'll find this feature useful.

Cheers.

Dejan

P.S.  I'm not subscribed to the list so please CC when appropriate.

[Dump-devel] Patch to add MB output to dump

[International M. of M. <wc...@na...>]

This patch makes dump report the MB of records dumped.  While it's
somewhat redundant, it's easier for scripts to search for \((.+)MB\) and
it's what Solaris' ufsdump does, so report scripts can have a little less
logic.

I'm not completely sure 'blockswritten' is what I should have used, so if
the patch isn't right, consider it a feature-request :)

Also, I fixed a very minor spelling error by changing 'volumes(s)' to
'volume(s)'.  This wasn't included in the patch I posted to the
SourceForge patch manager, but should be in the one included with this
message.

Wil
-- 
W. Reilly Cooley                         wc...@na...
The LNX System: Linux for a 2U case.         http://lnxs.org

I go on working for the same reason a hen goes on laying eggs.
		-- H.L. Mencken

Re: [Dump-devel] Some notes/patch for building dump

[Stelian P. <po...@cy...>]

On Thu, 24 Feb 2000, Andreas Dilger wrote:

> There are a couple minor things I noticed when building dump on my system:
> 1) even though I've done it properly before, it is not obvious when installing
>    e2fsprogs that you need to run "make install-libs" and not just "make
>    install", so it would be nice to have a note to that effect in the
>    configure error message for ext2fs_lib.

Added.

> 2) It's nice to get "PWD" when using restore in interactive mode.  I have it
>    tied to verbose mode, but it could also just be the default mode, or have
>    its own "prompt" mode or something.

Added.

> 3) The default tape device for dump and mt are not the same.

Delayed. I will take this into account for the next version of
dump (coming with an imporoved configure, seds into the man pages 
etc).

> 4) I removed a bit of unused cruft.

Done.

All this is already in the CVS.

Thanks for the patch.

Stelian.

Stelian.
-- 
    /\ 
   /  \     Stelian Pop
  / DS \                        Email: po...@cy...
  \____/ 

[Dump-devel] Some notes/patch for building dump

[Andreas D. <ad...@ho...>]

Hello,
I've been using ext2 dump since way back, and I have to say it's great that
someone is maintaining it again (I had previously sent bug reports to the
Debian maintainer).

There are a couple minor things I noticed when building dump on my system:
1) even though I've done it properly before, it is not obvious when installing
   e2fsprogs that you need to run "make install-libs" and not just "make
   install", so it would be nice to have a note to that effect in the
   configure error message for ext2fs_lib.
2) It's nice to get "PWD" when using restore in interactive mode.  I have it
   tied to verbose mode, but it could also just be the default mode, or have
   its own "prompt" mode or something.
3) The default tape device for dump and mt are not the same.
4) I removed a bit of unused cruft.

I've included a patch which will do these things below.  As I don't know
anything about autoconf, I haven't added a check for <sys/mtio.h>, which
might be a better solution than my code.

Cheers, Andreas
--- cut here ---
diff -ru dump-0.4b14/configure dump-0.4b14a/configure
--- dump-0.4b14/configure	Sun Nov 21 08:39:46 1999
+++ dump-0.4b14a/configure	Thu Feb 24 13:04:32 2000
@@ -1632,7 +1632,7 @@
 fi
 
 if test "$ext2fs_h" = no -o "$ext2fs_lib" = no; then
-	{ echo "configure: error: You need to install the Ext2fs libraries from the E2fsprogs distribution first" 1>&2; exit 1; }
+	{ echo "configure: error: You need to install the Ext2fs libraries from the E2fsprogs distribution first - hint: make install-libs" 1>&2; exit 1; }
 fi
 
 for ac_func in err errx verr verrx vwarn vwarnx warn warnx realpath lchown
diff -ru dump-0.4b14/configure.in dump-0.4b14a/configure.in
--- dump-0.4b14/configure.in	Sun Nov 21 08:39:46 1999
+++ dump-0.4b14a/configure.in	Thu Feb 24 13:03:57 2000
@@ -226,7 +226,7 @@
 AC_CHECK_HEADER(ext2fs/ext2fs.h, [ext2fs_h=yes], [ext2fs_h=no])
 AC_CHECK_LIB(ext2fs, ext2fs_open, [ext2fs_lib=yes], [ext2fs_lib=no], [-lcom_err])
 if test "$ext2fs_h" = no -o "$ext2fs_lib" = no; then
-	AC_MSG_ERROR(You need to install the Ext2fs libraries from the E2fsprogs distribution first)
+	AC_MSG_ERROR(You need to install the Ext2fs libraries from the E2fsprogs distribution first - hint: make install-libs)
 fi
 
 dnl
diff -ru dump-0.4b14/dump/dump.h dump-0.4b14a/dump/dump.h
--- dump-0.4b14/dump/dump.h	Thu Feb 24 12:45:56 2000
+++ dump-0.4b14a/dump/dump.h	Thu Feb 24 12:21:15 2000
@@ -71,7 +71,6 @@
 char	tape[NAME_MAX];	/* name of the tape file */
 char	*tapeprefix;	/* prefix of the tape file */
 char	*dumpdates;	/* name of the file containing dump date information*/
-char	*temp;		/* name of the file for doing rewrite of dumpdates */
 char	lastlevel;	/* dump level of previous dump */
 char	level;		/* dump level of this dump */
 int	uflag;		/* update flag */
diff -ru dump-0.4b14/dump/main.c dump-0.4b14a/dump/main.c
--- dump-0.4b14/dump/main.c	Thu Feb 24 12:45:56 2000
+++ dump-0.4b14a/dump/main.c	Thu Feb 24 12:59:41 2000
@@ -144,7 +144,6 @@
 	if ((tapeprefix = getenv("TAPE")) == NULL)
 		tapeprefix = _PATH_DEFTAPE;
 	dumpdates = _PATH_DUMPDATES;
-	temp = _PATH_DTMP;
 	strcpy(labelstr, "none");	/* XXX safe strcpy. */
 	if (TP_BSIZE / DEV_BSIZE == 0 || TP_BSIZE % DEV_BSIZE != 0)
 		quit("TP_BSIZE must be a multiple of DEV_BSIZE\n");
diff -ru dump-0.4b14/dump/tape.c dump-0.4b14a/dump/tape.c
--- dump-0.4b14/dump/tape.c	Thu Feb 24 12:45:56 2000
+++ dump-0.4b14a/dump/tape.c	Thu Feb 24 13:00:49 2000
@@ -732,10 +732,11 @@
 			msg("Dumping volume %d on %s\n", tapeno, tape);
 		}
 #ifdef RDUMP
-		while ((tapefd = (host ? rmtopen(tape, 2) :
-			pipeout ? 1 : open(tape, O_WRONLY|O_CREAT, 0666))) < 0)
+		while ((tapefd = (host ? rmtopen(tape, 2) : pipeout ?
+				  fileno(stdout) :
+				  open(tape, O_WRONLY|O_CREAT, 0666))) < 0)
 #else
-		while ((tapefd = (pipeout ? 1 :
+		while ((tapefd = (pipeout ? fileno(stdout) :
 				  open(tape, O_WRONLY|O_CREAT, 0666))) < 0)
 #endif
 		    {
diff -ru dump-0.4b14/restore/interactive.c dump-0.4b14a/restore/interactive.c
--- dump-0.4b14/restore/interactive.c	Fri Jan 21 03:17:41 2000
+++ dump-0.4b14a/restore/interactive.c	Thu Feb 24 12:50:05 2000
@@ -337,7 +337,11 @@
 	 * Read a command line and trim off trailing white space.
 	 */
 	do	{
-		fprintf(stderr, "%s > ", __progname);
+		if (vflag)
+			fprintf(stderr, "%s:%s:%s > ", __progname,
+				spcl.c_filesys, curdir[1] ? &curdir[1] : "/");
+		else
+			fprintf(stderr, "%s > ", __progname);
 		(void) fflush(stderr);
 		(void) fgets(input, BUFSIZ, terminal);
 	} while (!feof(terminal) && input[0] == '\n');
diff -ru dump-0.4b14/compat/include/pathnames.h dump-0.4b14a/compat/include/pathnames.h
--- dump-0.4b14/compat/include/pathnames.h	Fri Jan 21 03:17:41 2000
+++ dump-0.4b14a/compat/include/pathnames.h	Thu Feb 24 14:25:23 2000
@@ -42,7 +42,10 @@
 
 #include <paths.h>
 
+#ifdef __linux__
+#include <sys/mtio.h>
+#define _PATH_DEFTAPE	DEFTAPE
+#else
 #define	_PATH_DEFTAPE	"/dev/st0"
-#define	_PATH_DTMP	"/etc/dtmp"
-#define	_PATH_LOCK	"/tmp/dumplockXXXXXX"
+#endif /* __linux__ */
 #define	_PATH_RMT	"/etc/rmt"		/* path on remote host */
--- cut here ---
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [Dump-devel] remote dump fails

[Stelian P. <po...@cy...>]

On Fri, 11 Feb 2000, Frank Koormann wrote:

> Performing remote dumps I use ssh instead of rsh.
> However due to changes in common/dumprmt.c (1.11)
> the password is no langer transfered to the ssh
> but can be seen in plain text on the console.
> 
> I don't think this is really a bug but only a
> smaller problem. Hence I am refering to this list.

Yes, I am aware of this issue, but it's not that simple
to deal with it...

The old way to handle RSH caused the rsh process (ssh in
your case) to be killed when the user pressed ^C. Dump
itself catches the signal and asks if you really want to
abort the dump. If you respond with 'no', you're out
of luck because ssh itself catched the signal and died.
So the backup will fail. This is what the patch solved.

The only way to make ssh not interpret the ^C was to
put it into a new process group, detached from the
terminal. The ^C works this way, but ssh, since it has
no more a terminal to read from, cannot ask anymore
for a password... The solution would be to make ssh
not ask for a password, using one of its RSAHosts or
RSA methods of authentificate.

Both two ways are not satisfying me, but I don't see
any either solution...

Stelian.
-- 
    /\ 
   /  \     Stelian Pop
  / DS \                        Email: po...@cy...
  \____/ 

[Dump-devel] remote dump fails

[Frank K. <arc...@db...>]

This message was sent from Geocrawler.com by "Frank Koormann" <fra...@in...>
Be sure to reply to that address.

Hi Folks,

I have just updated from 0.4b12 to 0.4b14. 

Performing remote dumps I use ssh instead of rsh.
However due to changes in common/dumprmt.c (1.11)
the password is no langer transfered to the ssh
but can be seen in plain text on the console.

I don't think this is really a bug but only a
smaller problem. Hence I am refering to this list.

Is there already a patch to solve this. A work
around for me was to replace the file by the
former version (1.08) from the 0.4b12 package.

Regards,

	Frank

Geocrawler.com - The Knowledge Archive

Re: [Dump-devel] Weird problems with latest dump and exabyte

[Stelian P. <st...@ca...>]

On Thu, 10 Feb 2000, Denis Gerasimov wrote:

> On Thu, 10 Feb 2000, Stelian Pop wrote:
> 
> > Stelian Pop wrote:
> > Do the latest release (0.4b14) still give the same error?
> 
> Stelian and others,
> I apologize for this. It was all my fault. I was playing with drive
> firmware before the failures and forgot to restore the original (working)
> firmware. dump is working fine. 

You mean playing with the tape drive firmware (not the hard drive). Another user
reported a problem similar to yours, maybe it's the same cause (the bug is filled 
in the sourceforge bug section).

Anyway, happy to hear it was not a dump problem..

> It does sometimes miscalculate size of the
> volume (and ends up with messages like:

Miscalculation is normal (I mean it's not perfect, it's only an approximation).
But reporting negative time counts or more than 100% it is a bug, which was fixed in
0.4b14.

Stelian.
-- 
Stelian Pop <sp...@ca...>| Too many things happened today
Captimark                      | Too many words I don't wanna say
Paris, France                  | I wanna be cool but the heat's coming up
                               | I'm ready to kill 'cause enough is enough
PGP key available on request   |              (Accept - "Up To The Limit")

Re: [Dump-devel] Weird problems with latest dump and exabyte

[Denis G. <de...@da...>]

On Thu, 10 Feb 2000, Stelian Pop wrote:

> Stelian Pop wrote:
> Do the latest release (0.4b14) still give the same error?

Stelian and others,
I apologize for this. It was all my fault. I was playing with drive
firmware before the failures and forgot to restore the original (working)
firmware. dump is working fine. It does sometimes miscalculate size of the
volume (and ends up with messages like:
  DUMP: estimated 1126323 tape blocks.
....
  DUMP: 93.08% done, finished in 0:02
  DUMP: 109.01% done, finished in 0:-3
  DUMP: DUMP: 1230156 tape blocks on 1 volumes(s)
but this is minor.)

Dennis Gerasimov

Re: native :) Re: [Dump-devel] RE: FreeBSD

[Stelian P. <st...@ca...>]

On Thu, 10 Feb 2000, Rob Cermak wrote:

> Just making sure that it was native or the new ones :)

I meant native BSD dump (in order to have a dump file which has the
'reference' format...).

> I think /etc on most systems these days have all file types.

There are no devices on /etc, and maybe no hard links either... And
BSD have something that linux ext2 doesn't support: file with holes. I
don't know how to find if a file has holes in it, but it would be 
interesting to see how we can deal (I mean linux restore) with such 
a file ...

Stelian.
-- 
Stelian Pop <sp...@ca...>| Too many things happened today
Captimark                      | Too many words I don't wanna say
Paris, France                  | I wanna be cool but the heat's coming up
                               | I'm ready to kill 'cause enough is enough
PGP key available on request   |              (Accept - "Up To The Limit")

native :) Re: [Dump-devel] RE: FreeBSD

[Rob C. <ce...@IM...>]

Just making sure that it was native or the new ones :)

I'll try and figure out the md5 checksum things.   I've
used them before...

I think /etc on most systems these days have all file types.

More later... Rob

Re: [Dump-devel] Weird problems with latest dump and exabyte

[Stelian P. <po...@cy...>]

Stelian Pop wrote:
> 
> Denis Gerasimov wrote:
> >
> > Folks,
> > I have upgraded from 0.4b4 to 0.4b13 and now I have a weird write error. I
> > use exabyte 8505XL drives (tried with two of them). The error:
> >   DUMP: write error 2620 blocks into volume 1
> >   DUMP: Do you want to restart?: ("yes" or "no")
> 

Do the latest release (0.4b14) still give the same error?

Stelian.
-- 
Stelian Pop <sp...@ca...>| Too many things happened today
Captimark                      | Too many words I don't wanna say
Paris, France                  | I wanna be cool but the heat's coming up
                               | I'm ready to kill 'cause enough is enough
PGP key available on request   |              (Accept - "Up To The Limit")

Re: [Dump-devel] Results of sparc patch / too much testing...

[Stelian P. <po...@cy...>]

Stelian Pop wrote:

> Anyway, tomorrow at work I'll try more in detail the HP/UX dump,
> which seemed to me to be compatible with the Linux version (but I
> didn't check the integrity of the binary data).

I've checked it and:

- linux restore is able to read a HP/UX dump (including binary files -
although HP/UX dumps seems to be of an old dump tape format).

- the HP/UX restore coredumps when trying to read a linux dump...

I'd say that the HP/UX restore is buggy, and that linux dump/restore
is correct.

Stelian.
-- 
Stelian Pop <sp...@ca...>| Too many things happened today
Captimark                      | Too many words I don't wanna say
Paris, France                  | I wanna be cool but the heat's coming up
                               | I'm ready to kill 'cause enough is enough
PGP key available on request   |              (Accept - "Up To The Limit")

Re: [Dump-devel] RE: FreeBSD

[Stelian P. <st...@ca...>]

On Wed, 9 Feb 2000, Rob Cermak wrote:

> I'm reluctant to say my wife has a FreeBSD laptop (IBM thinkpad).

Well well well..
> 
> You need some tests on that system?  That is my weakest platform
> with SGI.   All I can do is compile and try :)
> 
> The filesystem is different, but the dump/restore code should work
> on it?
> 

I don't think that the linux dump/restore code will compile any more
on FreeBSD... but this is not the point actually:

All that I would like you to do is make a dump of one of BSD's filesystems
, using the native dump, and send it to me (along with a, say md5sum of all
files, so I can test the integrity after restoring). The dump needs to be big
enough and needs to contains hard links, symlinks, devices, text files,
binary files, maybe some files with special BSD attributes (append-only,
secure deletion etc, do not know if this exists on BSD).

And second, using the native BSD restore, could you verify that you can 
read a linux dump?

This is however a low priority thing... do this when you'll have some time
to spare.

Thanks.

Stelian.

-- 
Stelian Pop <sp...@ca...>| Too many things happened today
Captimark                      | Too many words I don't wanna say
Paris, France                  | I wanna be cool but the heat's coming up
                               | I'm ready to kill 'cause enough is enough
PGP key available on request   |              (Accept - "Up To The Limit")

[Dump-devel] RE: FreeBSD

[Rob C. <ce...@IM...>]

I'm reluctant to say my wife has a FreeBSD laptop (IBM thinkpad).

You need some tests on that system?  That is my weakest platform
with SGI.   All I can do is compile and try :)

The filesystem is different, but the dump/restore code should work
on it?

Rob

Re: [Dump-devel] Results of sparc patch / too much testing...

[Stelian P. <po...@cy...>]

On Wed, 9 Feb 2000, Rob Cermak wrote:

> Patch applied : success
> Compiled on RH 6.1 (sparc)/e2fsprogs-devel-1.17-1 : success
> 
> Linux to Linux:
> Dumped from sparc to tape, restore using sparc : ok
> Restored sparc dump to x86 : ok!
> Dumped from x86 to tape, restore using x86 : ok
> Restored x86 dump to sparc : ok!
>

Ok, so this is ready for the release! Thanks again for all those testings.
(but, if I believe what I read, you do like testing :) ).
 
> Based on the above and what I did below it looks like the Solaris
> ufsdump and ufsrestore are suspect.  You can move text around, but
> heaven hold your binaries :)

Well, my problem is that I have no "reference" BSD test dumps (and
I don't have a *BSD system, unless I decinde to install one to play 
with...).

So I can make no guarantee if linux dump format is really 100% compatible
with the BSD one... Some users did use that feature, and they were
reporting success, so I guess I'll have to trust them.

As for the Solaris ufsdump, I don't even know if it's the same as
FreeBSD one (although it should be...). So I don't see how we can
tell if the Solaris dump is buggy (or behaving differently), or if
the Linux dump is not correct. Both seems to do almost the same thing,
but in order to find which one is the bad guy, we will need to test
both of them with a reference FreeBSD dump.

Anyone in the audience have a Free/Net/OpenBSD machine ? 

Anyway, tomorrow at work I'll try more in detail the HP/UX dump,
which seemed to me to be compatible with the Linux version (but I
didn't check the integrity of the binary data).

In an optimal world, all dumps and restores would be compatible,
but maybe this is too utopic after all.

> But the SparcLinux works like a champ -- glad to be of some help in my
> limited capacity.   I'll await a new release and whip up the Sparc rpms.

Please do. 

>     The executable was not in the same state...  Gotta watch how your
>     molecules get scattered using the Enterprise transporters!
> 
> I thought it was kinda cute in that I've never seen that message before.

To boldly go when no one has gone before... Maybe the restore process was
disrupted by a tachyon beam or something. O'Brian should be more careful
in the future :)

> Doing a binary compare (cmp), it dies on byte 12289.
> [root@njlug pkgs]# cmp ls /bin/ls
> ls /bin/ls differ: char 12289, line 25

What is amazing is that text files works, and a binary file get corrupted 
only after 12000 bytes! If it had not worked at all, it would be
much simpler :)

> The Solaris box almost ran the SparcLinux dump executable (just testing
> out of curiousity) -- it ended up looking for the linux loader...

You really like to do strange things... :)

> NOTE: I don't expect x86 or sparc linux executables to run on Solaris.

I was wondering... :)


-- 
    /\ 
   /  \     Stelian Pop
  / DS \                        Email: po...@cy...
  \____/ 

[Dump-devel] Results of sparc patch / too much testing...

[Rob C. <ce...@IM...>]

Patch applied : success
Compiled on RH 6.1 (sparc)/e2fsprogs-devel-1.17-1 : success

Linux to Linux:
Dumped from sparc to tape, restore using sparc : ok
Restored sparc dump to x86 : ok!
Dumped from x86 to tape, restore using x86 : ok
Restored x86 dump to sparc : ok!

One more test -- as a result of the dump/restore/dump dilemma seen
using Solaris.

Acid testing: 
  1. Dump using x86
  2. Restore using sparc
  3. Dump same stuff using sparc
  4. Restore using x86
  5. Check executable to see if its ok to use

Acid test result: ok!

Ok, last one, reverse of last to see if x86 mangles sparc executables,
result: passed!  Rock on...

Based on the above and what I did below it looks like the Solaris
ufsdump and ufsrestore are suspect.  You can move text around, but
heaven hold your binaries :)

IGNORE the rest if you'd like --- the SparcLinux items work now.
Don't know if it'd be too much of a chore to figure out what is
going on to enable Solaris compatilibity with Linux.  I haven't
given the Solaris/Linux emulator a try.  Low priority hacking...

But the SparcLinux works like a champ -- glad to be of some help in my
limited capacity.   I'll await a new release and whip up the Sparc rpms.

Rob Cermak
----------------------------------------------------------------------

Misc compatibility tests with Solaris 2.6 (ufsdump/ufsrestore):

Restored x86 linux dump to sparc Solaris 2.6 (ufsrestore) : ok
Restored sparc linux dump to sparc Solaris 2.6 (ufsrestore) : ok

Dumped from Solaris 2.6 using ufsdump --

   Read using sparc linux: works? (*)
   Read using x86   linux: works? (*)

(*) Looks like text files are ok, but there is some mangling of
    the executable.   The x86 ls that I dumped on the Solaris side
    was put to tape using ufsdump and on the x86 side was restored.
    The executable was not in the same state...  Gotta watch how your
    molecules get scattered using the Enterprise transporters!

Don't know if you want to go here or not.  The results you get when
you run the restored ls is:

x86->Solaris->x86:
[root@njlug pkgs]# ./ls
BUG IN DYNAMIC LINKER ld.so: dynamic-link.h: 57: elf_get_dynamic_info: Assertion `! "bad dynamic
tag"' failed!

I thought it was kinda cute in that I've never seen that message before.

Doing a binary compare (cmp), it dies on byte 12289.
[root@njlug pkgs]# cmp ls /bin/ls
ls /bin/ls differ: char 12289, line 25

Solaris 2.6:
The Solaris box almost ran the SparcLinux dump executable (just testing
out of curiousity) -- it ended up looking for the linux loader...
magellan1{root}139: file dump
dump:  ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped
magellan1{root}140: ./dump
dump: Cannot find /lib/ld-linux.so.2
Killed

NOTE: I don't expect x86 or sparc linux executables to run on Solaris.

Re: [Dump-devel] sparc vs x86 info/dumps etc....

[Stelian P. <st...@ca...>]

On Tue, 8 Feb 2000, Stelian Pop wrote:

> On Tue, 8 Feb 2000, Rob Cermak wrote:
> 
> > Dumps from dumpe2fs, the file systems are the same type and block size,
> > groupings are a bit different.  See information below.
> 
> Ok, I'll try to debug this tomorrow...

Ok, here it is (see the attached patch, to be applied to 0.4b13).

Please test if this works, in all four directions (sparc-sparc,
x86-sparc, sparc-x86, x86-x86), and report me the results. I would
like to include this patch in the next release (which I would like to
make at the end of this week).

> > Right from the get-go the simple command dump 0S sparc on both
> > systems produce differnet results:
> 
> Strange... maybe normal but worth a look at the code...

After having looked at the code this is normal, because, when dumping a
subset of a filesystem, all the entries of each directory on the path from
the root to the directory to be dumped are dumped (the contents of the entry 
is not dumped, only the inode). And you had more entries like these on
the sparc filesystem that on the intel one.

Stelian.
-- 
Stelian Pop <sp...@ca...>| Too many things happened today
Captimark                      | Too many words I don't wanna say
Paris, France                  | I wanna be cool but the heat's coming up
                               | I'm ready to kill 'cause enough is enough
PGP key available on request   |              (Accept - "Up To The Limit")

Re: [Dump-devel] sparc vs x86 info/dumps etc....

[Stelian P. <po...@cy...>]

On Tue, 8 Feb 2000, Rob Cermak wrote:

> Dumps from dumpe2fs, the file systems are the same type and block size,
> groupings are a bit different.  See information below.

Ok, I'll try to debug this tomorrow...

> Right from the get-go the simple command dump 0S sparc on both
> systems produce differnet results:

Strange... maybe normal but worth a look at the code...

> [Do you have the Commercial version of secureshell installed 2.0.13?
>   If so, I can give you access to a 'SparcLinux' box...just send me a
>   public key and we can go from there.

I still use ssh-1.2.27, for license reasons...

Ok, expect to here from me tomorrow, if all goes right. :)

Stelian.
-- 
    /\ 
   /  \     Stelian Pop
  / DS \                        Email: po...@cy...
  \____/ 

[Dump-devel] sparc vs x86 info/dumps etc....

[Rob C. <ce...@Ru...>]

Dumps from dumpe2fs, the file systems are the same type and block size,
groupings are a bit different.  See information below.

I created a directory with a file in it...

x86:
[root@njlug /root]# ls -l sparc
total 4
-rw-r--r--   1 root     root         3782 Feb  8 15:38 rpm.list

sparc:
[root@bismark /root]# ls -l sparc
total 4
-rw-r--r--   1 root     root         3782 Feb  8 14:46 rpm.list

Right from the get-go the simple command dump 0S sparc on both
systems produce differnet results:

x86:
[root@njlug /root]# dump 0S sparc
49152

sparc:
[root@bismark /root]# dump 0S sparc
70656

I'll put the two tapedumps on the website with the sparc RPMs.
   tapefile.sparc  [dump 0f tapefile.sparc sparc]
   tapefile.x86    [dump 0f tapefile.x86 sparc]

[Do you have the Commercial version of secureshell installed 2.0.13?
  If so, I can give you access to a 'SparcLinux' box...just send me a
  public key and we can go from there.
      http://www.rge.com/pub/security/ssh/ssh-2.0.13.tar.gz          ]

NOTES:

x86:

Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          0a009856-4b1e-11d3-9035-0080c85aff68
Filesystem magic number:  0xEF53
Filesystem revision #:    0 (original)
Filesystem features:     (none)
Filesystem state:         not clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              64512
Block count:              258016
Reserved block count:     12900
Free blocks:              89275
Free inodes:              43410
First block:              1
Block size:               1024
Fragment size:            1024
Blocks per group:         8192
Fragments per group:      8192
Inodes per group:         2016
Inode blocks per group:   252
Last mount time:          Mon Feb  7 13:59:58 2000
Last write time:          Tue Feb  8 15:41:19 2000
Mount count:              17
Maximum mount count:      20
Last checked:             Wed Oct 13 05:55:38 1999
Check interval:           15552000 (6 months)
Next check after:         Mon Apr 10 05:55:38 2000
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)

sparc:

Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          2f24d4a0-da2d-11d3-8a8e-08002004d239
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      filetype sparse_super
Filesystem state:         not clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              117856
Block count:              471200
Reserved block count:     23560
Free blocks:              86564
Free inodes:              85360
First block:              1
Block size:               1024
Fragment size:            1024
Blocks per group:         8192
Fragments per group:      8192
Inodes per group:         2032
Inode blocks per group:   254
Last mount time:          Mon Feb  7 13:30:04 2000
Last write time:          Tue Feb  8 16:39:10 2000
Mount count:              3
Maximum mount count:      20
Last checked:             Thu Feb  3 06:29:32 2000
Check interval:           15552000 (6 months)
Next check after:         Tue Aug  1 07:29:32 2000
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128

x86: 
[root@njlug /root]# dump 0f tapefile.x86 sparc
  DUMP: Date of this level 0 dump: Tue Feb  8 15:53:06 2000
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/hda1 (/) to tapefile.x86
  DUMP: Label: none
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 49 tape blocks on 0.00 tape(s).
  DUMP: Volume 1 started at: Tue Feb  8 15:53:06 2000
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: DUMP: 40 tape blocks on 1 volumes(s)
  DUMP: finished in less than a second
  DUMP: Volume 1 completed at: Tue Feb  8 15:53:06 2000
  DUMP: DUMP: Date of this level 0 dump: Tue Feb  8 15:53:06 2000
  DUMP: DUMP: Date this dump completed:  Tue Feb  8 15:53:06 2000
  DUMP: DUMP: Average transfer rate: 0 KB/s
  DUMP: Closing tapefile.x86
  DUMP: DUMP IS DONE

sparc:
[root@bismark /root]# dump 0f tapefile.sparc sparc
  DUMP: Date of this level 0 dump: Tue Feb  8 16:52:55 2000
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/sda1 (/) to tapefile.sparc
  DUMP: Label: none
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 70 tape blocks on 0.00 tape(s).
  DUMP: Volume 1 started at: Tue Feb  8 16:52:55 2000
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: DUMP: 54 tape blocks on 1 volumes(s)
  DUMP: finished in less than a second
  DUMP: Volume 1 completed at: Tue Feb  8 16:52:56 2000
  DUMP: Volume 1 took 0:00:01
  DUMP: Volume 1 transfer rate: 54 KB/s
  DUMP: DUMP: Date of this level 0 dump: Tue Feb  8 16:52:55 2000
  DUMP: DUMP: Date this dump completed:  Tue Feb  8 16:52:56 2000
  DUMP: DUMP: Average transfer rate: 54 KB/s
  DUMP: Closing tapefile.sparc
  DUMP: DUMP IS DONE

Re: [Dump-devel] hard links in dump-0.4b13 (and earlier)

[Stelian P. <st...@ca...>]

On Mon, 7 Feb 2000, Ambrose Li [EDP] wrote:

> I noticed some files missing from a restore, then I noticed the
> comment about the schg flag in the linkit() code. After some
> digging around, I came up with the attached patch that at least
> allows me to do a full restore.

You're right, I included your patch in the CVS. Thanks.

As for the secure deletion flag, it is safe to zero the attributes 
(as long as we are restoring them after doing the link). The link
function does not modify (or overwrite, or delete) the original,
so it should be just fine.

Stelian.
-- 
Stelian Pop <sp...@ca...>| Too many things happened today
Captimark                      | Too many words I don't wanna say
Paris, France                  | I wanna be cool but the heat's coming up
                               | I'm ready to kill 'cause enough is enough
PGP key available on request   |              (Accept - "Up To The Limit")

[Dump-devel] hard links in dump-0.4b13 (and earlier)

[Ambrose Li [EDP] <ac...@mi...>]

I noticed some files missing from a restore, then I noticed the
comment about the schg flag in the linkit() code. After some
digging around, I came up with the attached patch that at least
allows me to do a full restore.

Perhaps someone more familiar with the ext2 routines should take
a look at the patch and see if there is anything wrong with it.

-- 
Ambrose Li / +1 416 321 0088 x272 / Ming Pao Newspapers (Canada) Ltd.
                                  / EDP Department @ Toronto
PGP fingerprint = 945C 2CF7 001D 5F03 B026  375F C5CF A55C 9F10 8B0E

Re: [Dump-devel] Weird problems with latest dump and exabyte

[Stelian P. <po...@cy...>]

Denis Gerasimov wrote:
> 
> Folks,
> I have upgraded from 0.4b4 to 0.4b13 and now I have a weird write error. I
> use exabyte 8505XL drives (tried with two of them). The error:
>   DUMP: write error 2620 blocks into volume 1
>   DUMP: Do you want to restart?: ("yes" or "no")

I never seen this kind of error before (at least nobody reported it), so I'll 
go towards a hardware problem (or a software one, concerning the driver for
your tape drive).

Just a few thoughts:
	- what are you using as dump's command line?
	- do you have the same problem when dumping into /dev/null or a /tmp file?
	- the exabyte is this a SCSI tape drive, and do you modprobe the driver
	before starting to dump (or you have the module inserted automatically
	when accessing to the tape).
	- any driver messages in /var/log/messages ?
	- is this a SMP system?
	- does a tar into that tape drive works?

I made a list of questions on the web page
(http://dump.sourceforge.net/REPORTING-BUGS),
could you please report the versions of your software as indicated on that 
page.

Maybe that will give me some supplementar clues...

Stelian.
-- 
Stelian Pop <sp...@ca...>| Too many things happened today
Captimark                      | Too many words I don't wanna say
Paris, France                  | I wanna be cool but the heat's coming up
                               | I'm ready to kill 'cause enough is enough
PGP key available on request   |              (Accept - "Up To The Limit")

[Dump-devel] Weird problems with latest dump and exabyte

[Denis G. <de...@da...>]

Folks,
I have upgraded from 0.4b4 to 0.4b13 and now I have a weird write error. I
use exabyte 8505XL drives (tried with two of them). The error:
  DUMP: write error 2620 blocks into volume 1
  DUMP: Do you want to restart?: ("yes" or "no") 

It repeats on different drives (all the same model), different tapes,
local (redhat 6.0 kernel 2.2.6) or remote (from mandrake 6.0 kernel 2.2.14
to redhat 6.0 kernel 2.2.6). The block number is always the same - 2620.

So I dug into the code and found out that a slave is getting a write
error. So I compiled dump with -DWRITEDEBUG, and added errno output to the
relevant printf, and I got:
.... (a lot of output snipped)
slave 2 wrote 10240
slave 0 wrote 10240
slave 1 wrote 10240
  DUMP: write: Input/output error
slave 2 wrote -1
slave 2 only wrote 0 out of 10240 bytes and gave up. errno=5, Input/output
error
  DUMP: write error 2620 blocks into volume 1, signal=10
  DUMP: Do you want to restart?: ("yes" or "no") no

At this point I am stuck (or too tired to think about this anymore).
Any suggestions?

-- Dennis Gerasimov

[Dump-devel] Re: sparc byteswap

[Rob C. <ce...@ah...>]

> > The rpms are built.  The sparc dumps them fine (via tape on i386), but the
> > i386 can't read them.  The sparc restore reads the tape dump fine.
> 
> I suppose that the sparc machine can read its own dumps at least, no? :)

The tape drive is on a x86.  Remote dump/restore works on the Sparc
works.  Pretty odd, but this might be good to know that it can read its
incorrectly written data?  I'll bet the sparc can't read a x86 dump...

Its when the x86 tries to read the sparc dump.

> Good. I should add a pointer on the web page to this... By the way, 
> on your page it should be 'rmt' instead of 'rpm' :)

Got it.
 
> Looks to me like some kind of byte swapping bug. This should be fixed,
> but unfortunatelly I don't have access to a sparc...
> 
> If you have some time, you can try to debug this.  I'll start by making
> two (small) file dumps, a x86 one and a Sparc one (of an empty directory,
> for example), then try to figure out the differences and track down up
> to the incriminated portion of code.
> 
> Send me the two dump, and I'll also try myself to see what's happening.

I'll see what I can do about getting two dumps to you; as well as a test
on if the sparc can read a x86 dump.

Rob