So does the statement from btape 'The last block of the first tape matches.' tell us that everything is ok even though the we received the error?
6-Mar 18:39 btape: Ready to read from volume "TestVolume1" on device "HPStorage Tape0" (Tape0). Rewinding. Reading the first 10000 records from 0:0. 10000 records read now at 1:5084 Reposition from 1:5084 to 148:13127 Reading block 13127. The last block of the first tape matches. Kern Sibbald wrote: > On Wednesday 28 March 2007 12:57, Brian Debelius wrote: > >> A workaround, which I do because i have not figured out how to correct >> this, is to just make sure your backups do not fill the tape. >> > > First, these problems are not normally fatal, but I wouldn't run my tape > drive > like that. > > Excluding tape/drive errors which produce similar problems, the most frequent > causes of this are: > > 1. Old tape drives that don't have a logical end of tape marker (this is not > likely to be the case except in drives manufactured more than 10 years ago). > > 2. Poor tape driver implementation. This is the most common cause. Tape > driver writers often don't really know what they are doing. The driver must > read the logical end of tape (this occurs before the physical end of the > tape) and must signal it to the program. In the Unix world most off brand > OSes do not signal the end of the tape. I won't mention their names other > than to say that Solaris, Linux, and I think FreeBSD, do so correctly. > Correctly signaling a logical end of tape means sending back a error status > to the write with an errno == ENOSPC then allowing the program to continue > writing until the hardware end of tape. > > Alternatively, the OS can signal with an error status and errno == EIO and > continue to allow the program to write until the physical end of the tape. > This is *much* less correct since Bacula does not know if it is a real error > condition or an end of tape. However, aside from the worrysome error > messages, the results are the same -- i.e. OK. > > The worst case is the OS signals an error status (errno = EIO) and does not > allow the program to write to the physical end of the tape. This is a bad > situation, but Bacula should handle it. At least the data can be recovered -- > in most cases. The problem is when the WEOF fails, one cannot be sure > whether or not the tape is properly terminated, and there is a chance that > some restore operation may read off the end of the tape. > > 3. Since I think we are talking about Win32, it is possible that the low > level > system calls (via mscrt.dll or whatever the name of the Microsoft > compatibility layer we use) is not well written to return reasonable/correct > statuses. This would be equivalent to poorly written Unix OS drivers I > mentioned above. > > >> brian- >> >> [EMAIL PROTECTED] wrote: >> >>> Can any one help us fix this problem ? (details below) >>> >>> Thank you >>> >>> Nawfel BERAICH >>> Casablanca 9h30 AM >>> >>> ----- Message d'origine ---- >>> De : Brian Debelius <[EMAIL PROTECTED]> >>> À : [EMAIL PROTECTED] >>> Cc : bacula-users@lists.sourceforge.net >>> Envoyé le : Mardi, 27 Mars 2007, 14h15mn 51s >>> Objet : Re : [Bacula-users] Re : Windows::Permission denied >>> >>> You are not to the point to start backing up files yet. This needs to >>> be fixed first. >>> >>> >>> [EMAIL PROTECTED] wrote: >>> >>>> Is it that blocking ? I think that with this kind of error bacula >>>> >>> will start the Job and fail while trying to finish it (because it's an >>> I/O error) but my bacula dont start writing the jobs ! it always say >>> that there is an error and stop without spending any time in writing >>> files... :-( ! >>> >>>> Thank you so much Brian for you precious help ! >>>> >>>> ----- Message d'origine ---- >>>> De : Brian Debelius <[EMAIL PROTECTED]> >>>> À : [EMAIL PROTECTED] >>>> Cc : bacula-users@lists.sourceforge.net >>>> Envoyé le : Mardi, 27 Mars 2007, 13h25mn 14s >>>> Objet : Re: Re : Re : Re : Re : [Bacula-users] Re : >>>> >>> Windows::Permission denied >>> >>>> Ok, you are now beyond my experience. Can someone help with fixing his >>>> EOF error? >>>> >>>> 26-Mar 18:35 btape: End of Volume "TestVolume1" at 148:13128 on device >>>> "HPStorag >>>> eTape0" (Tape0). Write of 64512 bytes got -1. >>>> 26-Mar 18:35 btape: btape Error: Error writing final EOF to tape. This >>>> Volume ma >>>> y not be readable. >>>> ../../stored/dev.c:1688 ioctl MTWEOF error on "HPStorageTape0" (Tape0). >>>> ERR=Inpu >>>> t/output error. >>>> >>>> brian- >>>> >>>> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share your >> opinions on IT & business topics through brief surveys-and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> Bacula-users mailing list >> Bacula-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bacula-users >> >> ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
