> So it looks like when Bacula/btape writes an EOF mark, this causes the > buffers to completely flush out and the drive then runs out of data > and is forced to stop and shoe-shine. > > I've had a look through the storage daemon options but I can't see > anything relevant. I take it disabling the writing of EOF marks is > not an option? Is there any way to somehow disable flushing on EOF?
So some investigation reveals that the MTWEOF ioctl does indeed flush the buffer. From the Linux st.txt: Writing filemarks without the immediate bit set in the SCSI command block acts as a synchronization point, i.e., all remaining data form the drive buffers is written to tape before the command returns. This makes sure that write errors are caught at that point, but this takes time. In some applications, several consecutive files must be written fast. The MTWEOFI operation can be used to write the filemarks without flushing the drive buffer. Writing filemark at close() is always flushing the drive buffers. However, if the previous operation is MTWEOFI, close() does not write a filemark. This can be used if the program wants to close/open the tape device between files and wants to skip waiting. It looks like others have encountered the same issue with other software[1], and switching to MTWEOFI fixed the problem there as well. So it looks like the solution is to change Bacula's tape_dev.c:951 from using MTWEOF to MTWEOFI. Support for MTWEOFI was added to the kernel[2] back in October 2010, and looks like it was first released in 2.6.37, so it's not something new. I am not familiar with Bacula's cross-platform support, so is this something that can simply be changed? Or could it just be wrapped by an `#ifdef MTWEOFI`? Cheers, Adam. [1] http://www.syncer.de/?p=862 [2] https://github.com/torvalds/linux/commit/3e51d3c924aea8a1f1372e6c615b0a37b528121d _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
