On Thursday 19 July 2007 13:49, Mariusz Czulada wrote: > Hi all, > > I didn't give up so made my own investigation. Now it seems I found the > source of my problem. I'll describe what I discovered. I need your help > to verify if it is a good way and how to include required changes into > bacula code. > > First reference materials: > > Programming reference (PRGOGREF): > ftp://ftp.software.ibm.com/storage/devdrvr/Doc/IBM_Tape_Driver_PROGREF.pdf > Setup and operator guide (SOG): > ftp://ftp.software.ibm.com/storage/3576R1_SOG.pdf > > And a remainder of my environment: > > I use an IBM xSeries host with CentOS 4.3. DDS-5 internal drive (working > perfectly), and IBM TS3310 tape library, with two LTO-3 drives connected > directly (i mean without FC switch) to two QLogic QLA2460 HBA. IBM tape > drivers taken from IBM site. Catalog is created in PostgreSQL 8.1.5. > Bacula 2.0.2. Both pg and bacula compiled from sources. > > ----------------- > > In my case, SD returned errno=5 (EIO) while executing DEVICE::fsf(). Not > very specific, just "something wrong" message. But, in PROGREF, p. 161 I > found: > > [...] > For error code EIO, an application can retrieve more information from the > device itself. Issue the STIOCQRYSENSE ioctl command when the > sense_type equals LASTERROR, or the SIOC_REQSENSE ioctl command, to > retrieve sense data. Then analyze the sense data using the appropriate > hardware or SCSI reference for that device. > [...] > > So went to SIOC_REQSENSE chapter for linux driver (p.123). There is an > example code I added in dev.c: > > [...] > } else if (at_eof() && errno == ENOSPC) { > stat = 0; > } else { > // ************** MQ - begin > struct request_sense sense_data; > int rc; > printf("Issuing request sense...\n"); > memset(&sense_data, 0, sizeof(struct request_sense)); > rc = ioctl(m_fd, SIOC_REQSENSE, &sense_data); > if (rc == 0) > { > if(!sense_data.err_code) > printf("No valid sense data returned.\n"); > else > { > /* print out data fields */ > printf("Information Field Valid Bit-----%d\n", sense_data.valid); > printf("Error Code----------------------0x%02x\n", sense_data.err_code); > printf("Segment Number------------------0x%02x\n", sense_data.segnum); > printf("filemark Detected Bit----------%d\n", sense_data.fm); > printf("End Of Medium Bit---------------%d\n", sense_data.eom); > printf("Illegal Length Indicator Bit----%d\n", sense_data.ili); > printf("Sense Key-----------------------0x%02x\n", sense_data.key); > if(sense_data.valid) > printf("Information Bytes-------------0x%02x 0x%02x 0x%02x 0x%02x\n", > sense_data.info >> 24, sense_data.info >> 16, > sense_data.info >> 8, sense_data.info & 0xFF); > printf("Additional Sense Length---------0x%02x\n", sense_data.addlen); > printf("Command Specific Information----0x%02x 0x%02x 0x%02x 0x%02x\n", > sense_data.cmdinfo >> 24, sense_data.cmdinfo >> 16, > sense_data.cmdinfo >> 8, sense_data.cmdinfo & 0xFF); > printf("Additional Sense Code-----------0x%02x\n", sense_data.asc); > printf("Additional Sense Code Qualifier-0x%02x\n", sense_data.ascq); > printf("Field Replaceable Unit Code-----0x%02x\n", sense_data.fru); > printf("Sense Key Specific Valid Bit----%d\n", sense_data.sksv); > if(sense_data.sksv) > { > printf("Command Data Block Bit--%d\n", sense_data.cd); > printf("Bit Pointer Valid Bit---%d\n", sense_data.bpv); > if(sense_data.bpv) > printf("System Information Message-0x%02x\n", sense_data.sim); > printf("Field Pointer----------------0x%02x%02x\n", > sense_data.field[0], sense_data.field[1]); > } > //dump_bytes(sense_data.vendor, 109, "Vendor"); > } > } > // ************** MQ - end > berrno be; > set_eot(); > [...] > > Almost copy/paste. Also added #include <sys/IBMtape.h>. 'make', then > 'make install'. Then started SD again with -d999 -f. And in the > problematic code I got following log: > > [...] > Issuing request sense... > Information Field Valid Bit-----1 > Error Code----------------------0x70 > Segment Number------------------0x00 > filemark Detected Bit----------0 > End Of Medium Bit---------------0 > Illegal Length Indicator Bit----0 > Sense Key-----------------------0x08 > Information Bytes-------------0x00 0x00 0xfc 0x00 > Additional Sense Length---------0x58 > Command Specific Information----0x00 0x00 0x00 0x00 > Additional Sense Code-----------0x00 > Additional Sense Code Qualifier-0x05 > Field Replaceable Unit Code-----0x30 > Sense Key Specific Valid Bit----0 > [...] > > So I have: > - sense key: 8 > - ASC/ASCQ: 00/05 > > "Drive sense data" chapter in SOG (p.C-8) describes this case as: > > [...] > 00 05 - EOD — Read or Space command terminated early > because End of Data was encountered > [...] > > IMHO it means that it is not *real* error, rather it is a special case > which shows that EOT was reached. So DEVICE::fsf() should continue it's > work... > > --------------------------------------- > > At this moment I'd like to ask you to verify if it seems correct and can > be coded as Yet Another Special Case.
First to talk about the code above: this is very special case code that is machine dependent, and so it is not really appropriate to add to Bacula, if that is what you are suggesting, as Bacula tries where ever possible to be platform neutral. In addition, most of the information you want above is normally placed in the system log. Concerning the error code returned and the special case which shows that an EOT was reached. I believe that this is either that you have not configured the directives in your Device resource correctly for your tape driver (not always easy) or a bug in the kernel scsi driver for that device. Bacula should not receive an I/O error code if an EOT is reached. I would recommend that you look at the existing Bacula code and assume it is correct, then figure out if there are any existing Bacula directives that allow you to adapt Bacula to properly interpret the codes that are coming back from the kernel driver. If this is not the case, then look at the codes that the Bacula device driver expects and complain to your OS supplier that his tape driver does not conform to Unix standards, which work perfectly fine on Linux, Solaris, and FreeBSD. One other thought, since you mention FC. You may be running with some software or hardware that is caching the data and status codes between the tape drive and Bacula. HP HBA's do so by default. Bacula works with the drive in synchronous mode. If something buffers data and/or returned status codes, it will *never* work with Bacula -- Bacula will not see the LEOT marker nor the EOT marker (status codes) at the correct time, so will fail. Regards, Kern > > > TIA for your comments, > > Mariusz Czułada > > ---------------------------------------------------- > Już w ten piątek Ty i Ona o godz. 16:00 w Sopocie na molo! Będziesz? > http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fd118.html&sid=1225 > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Bacula-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/bacula-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
