According to the docs and sd's tape-handling code, neither MTEOM nor 
FSF(0xffff…) will get used to quickly forward a tape to its end of data unless 
there's a working MTIOCGET ioctl that does EOF tracking. The reasoning being, 
that bacula uses files internally to track written data, so in order for 
append to tape to result in correct catalog entries, bacula must be using 
correct file numbers.

But considering backup tapes are typically exclusively used by a given backup 
system, isn't it the case that bacula knows *exactly* how many files there are 
on a given tape without having to rely on the tape drive doing the counting?

When I do a 'list volumes' in bconsole, one of the listed colums is 
'volfiles'. Is there any reason why that value can't be used after a 
MTEOM/FSF(0xfff…) for any further writes?

Or even a safer version for the paranoid:

maxf=get_volfiles()
fsf(maxf)
read()

If there's actual data there, abort (or rewind and do a fsf(1) loop), cause 
something's wrong. If read() indicates end of tape, we're ok. I can't think of 
a reason why it wouldn't be safe and I'm pretty sure that it would be a tad 
faster, then a looped fsf(1).

Comments?

--mmazur

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Reply via email to