On Monday 26 February 2007 21:18, Arno Lehmann wrote: > I send this to -users and -devel because I don't know if the original > poster is on -devel where this belongs, IMO... > > On 2/25/2007 3:43 AM, Dan Langille wrote: > > On 25 Feb 2007 at 3:33, Florian Heigl wrote: > >>Just a silent heads up, if I may... > > > > Umm, how is this silent? ;) > > Probably because Florian wrote that without mumbling the words while > typing? ;-) > > >>I never noticed bacula didn't track media errors, but this *is* a missing > >>feature
As far as I know, Bacula does keep track of all errors it encounters. One of the current problems on many operating systems is that they return an I/O error at the end of the tape (Linux handles it correctly, if I remember right), so tracking the errors may not be accurate. Bacula does not ask the SCSI controller for the "soft errors" -- i.e. those which are not seen by the program. > > Yes, and that's part of the reason for the feature request Adam and I > submitted some time ago :-) > > I wasn't aware of the difference between soft and hard errors, but > that's obviously important. > > >> - the backup tool is expected to have error counters for tape devices > >>and media, both will fail lots once things scale up as they're just parts > >> that wear off over time and one needs an indicator for replacing things > >> on time. > >> > >>usually a tape should be blocked from being recycled after a certain > >> point and a tape drive should be disabled for intervention. > > > > Sounds like you want to get this onto the projects page,and ready for > > the next vote. > > In my opinion that has already taken place: > Item 25: Improve Bacula's tape and drive usage and cleaning management. Yes, and I hope a big part of this can be resolved by Python scripting even if most users may not like this idea. It will in the long run provide a lot more flexibility. Perhaps in the next major release, someone (or I) can create a nice set of Python scripts that really do something useful and can be a sort of "default" that users can tweak as they wish ... > > Currently item 7 - and I notice that the projects page on the web site > is kind of broken. The overview and the actual descriptions are not > representing the current state, I believe. The projects file that is in the trunk of the SVN should be pretty close to the current state as I recently updated it. > > > Or someone could just do the work. If this is to be done, it must be > > modular: not every OS will collect the errors the same way. It may > > even differ from device to device. > > I had discussed some of that with Kern quite a while ago. > > He suggested to keep the 'status poller' in an extra script or program, > similar to mtx-changer. > > That does sound reasonable, and there even is a configuration directive > for that purpose in existence: AlertCommand. > > We would only need a defined interface to return status information in a > way that the SD can easily parse. In the thread 'Cleaning Jobs' on > -users I presented some ideas that could be used, because the problem of > cleaning job and this one here are tightly related: Basically, and as a > first step, it's about getting status information from the drive at > regular intervals. > > These need to be passed to the DIR, which could put them into the > catalog, and which would have to determine if any action is necessary - > drive cleaning, requesting operator assistence, or disabling the drive > or tape altogether. > > Looks like Adam and I did not understand what our feature request should > have contained, but we can always rewrite it. Quite soon, possibly :-) Good idea -- you might also discuss with Eric what he is currently working on for tracking Device statistics since he is currently implementing many things that you will probably want (real read/write times, ...). Also, I met Andrew Morton (the stable Linux kernel maintainer) at FOSDEM, and he agreed with me that the current Linux tape interface is rather primitive and promised to help me get in touch with the SCSI kernel developer. I would like to see some significant improvements in the information returned by ioctl() -- mainly whether or not there is a tape in the drive, but perhaps we can define an interface that will directly return a lot of the tape statistics that interest us (tape soft/hard errors, read/write counts/times, ...). ------------------------------------------------------------------------- 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
