Hi, 10.09.2007 02:23,, Ivan Adzhubey wrote:: > Arno, > > On Sunday 09 September 2007 08:07:42 pm Arno Lehmann wrote: >> Hi, >> >> 10.09.2007 00:51,, Ivan Adzhubey wrote:: >> ... >> >>> On a related issue: I have asked this question before but never get any >>> answer. >>> >>> Documentation states (from Data Spooling article): >>> >>> "While the spooled data is being written to the tape, the despooling >>> process has exclusive use of the tape. This means that you can spool >>> multiple simultaneous jobs to disk, then have them very efficiently >>> despooled one at a time without having the data blocks from several jobs >>> intermingled, thus substantially improving the time needed to restore >>> files. While despooling, all jobs spooling continue running." >>> >>> I have always had spooling enabled and the behaviour I observed through >>> several versions of Bacula (from 1.36.2 to 2.2.1) was never anything like >>> the described above. In reality, with simultaneous jobs enabled, several >>> jobs were happily despooling to the same tape drive simultaneously (until >>> I take countermeasures in the configuration to prevent this) wrecking >>> havoc on my tapes. I think the documented behaviour would make much sense >>> and would have prevented the MediaId bug from stricking. If only it would >>> be actually implemented... >> My experience is quite different and fits the manual: While one job is >> despooling, all other jobs using the same tape drive are either >> spooling (no problem) or waiting for despooling. This is the case on >> Bacula versions from 1.38.something to 2.0.3 at least. > > I am pretty sure I've witnessed this wrong behavior with my own eyes last > time > with version 2.2.0 but I might as well be misinterpreting what was going on. > But if you are right and simultaneous tape writes from different jobs should > never happen with spooling enabled, does this mean that this dreaded MediaId > bug should not occure with this configuration too? Sorry, this is a question > for Kern I guess.
I'll perhaps be able to post an example of what I observe this night. It might be difficult, because I'm out of the office then, but we'll see... let's compare the actual setups if we see different behaviour then. >> I would suggest to turn on debug logging before the jobs start and >> trace what the SD does, until more than one job actually writes to >> tape. At a debug level that reports the device reservation process and >> actual block writes to tape, the resulting trace will might get really >> huge, though... >> >> Anyway, perhaps you can identify where the SD allows multiple jobs >> write access to the storage device - I found that I could understand >> the trace file quite easily. > > Debugging on a production system is not what I am after frankly. I can understand that quite well, but this sort of debugging - theoretically, as well as what my experience confirms - does not affect the process of backing up or the reliability of your backups. It simply writes commented checkpoint information to a file. The only downsides I see are - a small performance hit, because of additional I/O during backups, - disk space is used. Depending on the debug level and the time you let it run with tracing enabled, LOTS of disk space. > We've already > lost 2 months of backups due to problems with hardware and software upgrades > on the server and right now I just can't stretch my luck any more. I may give > it another shot later after I've run through at least one straight backup > cycle though. I agree. I guess I'd make sure I have proper backups first in a situation like this. Anyway, provided I find the necessary time, I'll gladly help you analyzing any trace files you produce and compare them with what I observe. > At the moment, I would stick with the confuration workarounds I > have in place already. I've learned them hard way ;). That happens too often, IMO - Bacula is definitely too flexible to allow simple setups ;-) We really need a good technical writer to create a short, concise and exact "Getting Started" manual, but the necessary skills are, unfortunately, not very common among open source people. Arno -- Arno Lehmann IT-Service Lehmann www.its-lehmann.de ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
