On 2 Feb at 23:59 "Dustin J. Mitchell" <[EMAIL PROTECTED]> wrote in message
<[EMAIL PROTECTED]>
> On Feb 1, 2008 6:38 AM, Tony van der Hoff <[EMAIL PROTECTED]> wrote:
> > Meanwhile, and maybe easier to diagnose, I find:
>>GMT_ONLINE
> > [EMAIL PROTECTED]:~$ sudo ammt -t /dev/nht0 status tapedev /dev/nht0 is
> > offline or has no loaded tape. /dev/nht0 status failed: Success
>>
> > Whereas:
>>
> > [EMAIL PROTECTED]:~$ sudo mt -t /dev/nht0 status drive type = Generic SCSI-2
> > tape drive status = 512 sense key error = 0 residue count = 0 file
> > number = 0 block number = 0 Tape block size 512 bytes. Density code 0x0
> > (default). Soft error count since last status=0 General status bits on
> > (4000000):
>> WR_PROT
>>
> > I have attached the strace dumps for all 3 commands. Thanks again for
> > your help.
>
> From the strace, it looks like both applications (ammt and mt) are making
> the same syscalls, but getting different results:
>
> mt: open("/dev/nht0", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 3 fstat64(3,
> {st_mode=S_IFCHR|0660, st_rdev=makedev(37, 128), ...}) = 0 ioctl(3,
> MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE, 0xbfa50750) = 0
> ioctl(3, MGSL_IOCSTXIDLE or MTIOCGET or SNDCTL_MIDI_MPUCMD, 0xbfa50738) =
> 0
>
> ammt: open("/dev/nht0", O_RDONLY|O_LARGEFILE) = 3 ioctl(3, MGSL_IOCSTXIDLE
> or MTIOCGET or SNDCTL_MIDI_MPUCMD, 0xbf884cd8) = 0
>
> It comes from this code in taper-src/output-tape.c:
> 537 #ifdef GMT_ONLINE
> 538 if (!GMT_ONLINE(mt.mt_gstat)) {
> 539 close(ret);
> 540 fprintf(stderr, "tapedev %s is offline or has no loaded
> tape.\n",
> 541 filename);
> 542 return -1;
> 543 } 544 #endif /* GMT_ONLINE */
>
> So I think the only conclusion is that something in your config is buggy,
> and MTIOCGET is not returning an "ONLINE" state. Unfortunately, strace
> doesn't give us any insight into the contents of the 'mt' struct.
>
> The new device-src/tape-posix.c does a similar thing:
>
> 145 TapeCheckResult tape_is_ready(int fd) {
> 146 struct mtget get;
> 147 if (0 == ioctl(fd, MTIOCGET, &get)) {
> 148 #if defined(GMT_ONLINE) || defined(GMT_DR_OPEN)
> 149 if (1
> 150 #ifdef GMT_ONLINE
> 151 && GMT_ONLINE(get.mt_gstat)
> 152 #endif
> 153 #ifdef GMT_DR_OPEN
> 154 && !GMT_DR_OPEN(get.mt_gstat)
> 155 #endif
> 156 ) {
> 157 return TAPE_CHECK_SUCCESS;
> 158 } else {
> 159 return TAPE_CHECK_FAILURE;
> 160 }
> 161 #else /* Neither macro is defined. */
> 162 return TAPE_CHECK_UNKNOWN;
> 163 #endif
> 164 } else {
> 165 return TAPE_CHECK_FAILURE;
> 166 }
> 167 }
>
> Neither looks obviously incorrect, but I'm not well-versed in the posix
> tape interface. I think the best trick at this point may be to upgrade
> your kernel and/or tape drivers, but if you're interested in getting
> low-level, you could compile Amanda with debugging symbols (./configure
> ... CFLAGS=-g ...) and then run ammt under gdb, break on tape_tape_open,
> and investigate the contents of the 'mt' struct. As is always a
> frustration with hardware-related questions, this is not something anyone
> can investigate on your behalf :(
>
> Another solution may be to just delete lines 537-544, recompile, and see
> what happens.
OK, after some digging about, I find the following. Whether it's an Amanda
bug, or a kernel bug, I'll leave to more capable people to decide :)
>From the kernel sources, the Generic Magtape On-Line bit (GMT_ONLINE) is
defined by include/linux/mtio.h. However, this bit is presumably meaningful
for the SCSI tape interface (drivers/scsi/st.c), but has no meaning for the
IDE tape interface (drivers/ide/ide-tape.c), where a tape can't be taken
off-line. Consequently ide-tape.c does not return this flag (st.c does).
Looking at the sources for GNU mt and mt-st, neither makes any assumptions
about GMT_ONLINE, although mt-st (which is the SCSI-enhanced version of mt)
reports it if set.
Amanda, on the other hand, faults it if not set. In view of the kernel's
actions, this is probably a bit over-enthusiastic. It could be argued that
the kernel, having defined the flag in mtio.h, should just return it set for
an IDE tape, which I guess is what the now deprecated ide-scsi interface
did.
My upgrade to a later kernel, and abandoning ide-scsi in favour of ide-tape
has shown up this incompatibility.
My solution was to adopt Dustin's suggestion, and comment out the lines
537-544 in output-tape.c. It worked for me; but obviously a more permanent
fix is required.
Cheers, Tony
--
Tony van der Hoff | mailto:[EMAIL PROTECTED]
Buckinghamshire, England
