Hi Ned,
'twas emailed:
>
> This means that drive_scsitape.c/ds_match() scored badly.
> This means that
> rmtopen()
> or
> rmtioctl(fd, MTIOCGET, &mt_stat)
> failed.
>
> My bet, FOR SURE, is that rmtioctl(MTIOCGET) failed !!!!!
> Set the environment variable RMTDEBUG
> and watch the error messages.
> The rmtioctl code is in xfsdump/librmt/rmtioctl.c
> and is very UNIX specific. The "S" status command supported
> by rmt(1) varies quite a bit and there is special code in it
> for Linux and IRIX. For example, byte swapping may need
> to be done.
> If you want to use the scsitape strategy then the code in
> xfsdump/librmt/rmtioctl.c and rmtopen.c will have to be
> extended for Tru64.
>
> > Finally, just as a note, when dumping the IRIX machines, we normally use
> > the -m -b 245760 options, but these fail on the linux version with the
> > error:
> >
> > xfsdump: drive_minrmt.c:2201: do_end_write: Assertion `first_rec_w_err >=
> > 0' failed.
> >
> I'll have a look tomorrow - please redo with -v5.
>
Looking at he assertion failure...
If last write() succeeded then rval = 0, and first_rec_w_err = -1L;
Then if mt_op(MTWEOF) failed then rval = DRIVE_ERROR_EOM.
We would then have (first_rec_w_err == -1L && rval == DRIVE_ERROR_EOM)
and the assertion would fire.
My guess would be that mt_op(MTWEOF) failed.
mt_op(MTWEOF) = rmtioctl(MTIOCTOP, MTWEOF)
And for RMTHOST(filedes) == UNAME_UNKNOWN (in the case of Tru64,
as it is not "Linux" or "IRIX")
it does an rmt(1) command of "I" using the standard map of
operations:
#define STD_MTWEOF 0 /* write an end-of-file record */
#define STD_MTFSF 1 /* forward space file */
#define STD_MTBSF 2 /* backward space file */
#define STD_MTFSR 3 /* forward space record */
#define STD_MTBSR 4 /* backward space record */
#define STD_MTREW 5 /* rewind */
#define STD_MTOFFL 6 /* rewind and put the drive offline */
Check out /usr/include/sys/mtio.h and see what the values of
the mt ops are for Tru64.
On Linux MTWEOF is 5 and on IRIX MTWEOF is 0 and on an old
HP box we have MTWEOF is 0,
and on Linux, 0 is MTRESET, so you can see it is important
to get the values right !
So again, one needs to update librmt/rmtopen.c and librmt/rmtioctl.c
to add in a new host type for Tru64 and do all the necessary conversions
and mappings.
It's a real pain...but this is b/c no conventions were adopted for mt
values.
It would be good if a warning was generated for remote hosts
which are not supported and trying to use the rmtioctl's.
I'll look into this.
--Tim
|