> -----Original Message----- > From: Peter Zenge [mailto:pze...@ilinc.com] > Sent: Thursday, January 20, 2011 10:59 AM > To: bacula-users@lists.sourceforge.net > Subject: Re: [Bacula-users] SD Losing Track of Pool > > > -----Original Message----- > > From: Steve Ellis [mailto:el...@brouhaha.com] > > Sent: Thursday, January 20, 2011 10:39 AM > > To: bacula-users@lists.sourceforge.net > > Subject: Re: [Bacula-users] SD Losing Track of Pool > > > > On 1/20/2011 7:18 AM, Peter Zenge wrote: > > >> > > >>> Second, in the Device Status section at the bottom, the pool of > LF- > > F- > > >> 0239 is > > >>> listed as "*unknown*"; similarly, under "Jobs waiting to reserve > a > > >> drive", > > >>> each job wants the correct pool, but the current pool is listed > as > > >> "". > > >> > > > Admittedly I confused the issue by posting an example with two > Pools > > involved. Even in that example though, there were jobs using the > same > > pool as the mounted volume, and they wouldn't run until the 2 current > > jobs were done (which presumably allowed the SD to re-mount the same > > volume, set the current mounted pool correctly, and then 4 jobs were > > able to write to that volume concurrently, as designed. > > > > > > I saw this issue two other times that day; each time the SD changed > > the mounted pool from "LF-Inc" to "*unknown*" and that brought > > concurrency to a screeching halt. > > > > > > Certainly I could bypass this issue by having a dedicated volume > and > > device for each backup client, but I have over 50 clients right now > and > > it seems like that should be unnecessary. Is that what other people > > who write to disk volumes do? > > I've been seeing this issue myself--it only seems to show up for me > if > > a > > volume change happens during a running backup. Once that happens, > > parallelism using that device is lost. For me this doesn't happen > too > > often, as I don't have that many parallel jobs, and most of my > backups > > are to LTO3, so volume changes don't happen all that often either. > > However, it is annoying. > > > > I thought I had seen something that suggested to me that this issue > > might be fixed in 5.0.3, I've recently switched to 5.0.3, but haven't > > seen any pro or con results yet. > > > > On a somewhat related note, it seemed to me that during despooling, > all > > other spooling jobs stop spooling--this might be intentional, I > > suppose, > > but I think my disk subsystem would be fast enough to keep up one > > despool to LTO3, while other jobs could continue to spool--I could > > certainly understand if no other job using the same device was > allowed > > to start despooling during a despool, but that isn't what I observe. > > > > If my observations are correct, it would be nice if this was a > > configurable choice (with faster tape drives, few disk subsystems > would > > be able to handle a despool and spooling at the same time)--some of > my > > jobs stall long enough when this happens to allow some of my desktop > > backup clients to go to standby--which means those jobs will fail (my > > backup strategy uses Wake-on-LAN to wake them up in the first place). > > I > > certainly could spread my jobs out more in time, if necessary, to > > prevent this, but I like for the backups to happen at night when no > one > > is likely to be using the systems for anything else. I guess another > > option would be to launch a keepalive WoL script when a job starts, > and > > arrange that the keepalive program be killed when the job completes. > > > > -se > > > > > Agree about the volume change. In fact I'm running a backup right now > that should force a volume change in a couple of hours, and I'm > watching the SD status to see if the mounted pool becomes unknown > around that time. I have certainly noticed that long-running jobs seem > to cause this issue, and it occurred to me that long-running jobs also > have a higher chance of spanning volumes. > > If that's what I see, then I will upgrade to 5.0.3. I can do that > pretty quickly, and will report back... > >
Steve, I can confirm that it is the volume change that causes this issue. Luckily I can also confirm that it is fixed in 5.0.3. Shaved 18 hours off my backup window this past weekend! I should have upgraded to 5.0.3 before bothering the list. Thanks to everyone who responded. ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
