I agree with your logic. I have to admit I see these things with the bias of a user's perspective, not being an engineer.
At the same time, the NT (until 2002), 2000 (until 2005), and 2003 servers that I have used experienced measurably slower throughput and more faults (go in and get the process restarted) when using drivers than when not. This was important to me as even with 8 tape drives (more than one media/storage server) it took all night to run them, and I don't want it cutting into production's performance. I've never used a desktop OS for enterprise backups, so I don't know how that would work out - though I don't think the software would install on it. I hear that a lot of code is outsourced now-a-days, but, though possible, I doubt all 4 vendors used the same shop and got the same code. But, if they all studied at the same place and used the same routines..., who knows. Yes, well written Windows can do a good job. I just don't see why I would want to use something I don't need, and that might hinder resolving problems when do show up. On Thu, 2007-03-15 at 12:47 -0700, Robert Nelson wrote: > > > -----Original Message----- > > From: Don MacArthur [mailto:[EMAIL PROTECTED] > > Sent: Thursday, March 15, 2007 7:27 AM > > To: Robert Nelson > > Cc: bacula-users@lists.sourceforge.net > > Subject: Re: [Bacula-users] > > ***************URGENT************NeedHelp!*************** > > > > Hi Robert, > > > > This comment is in reference to the conversation about using HP Windows > > Drivers. > > > > In my conversations with HP and other vendors about drivers and tape > > drives on Windows, the consensus seemed to be that using Windows drivers > > created more problems that they solved. Their advice was to address the > > scsi devices directly. The benefits are increased throughput and fewer > > problems communicating with the devices. > > > > I think this may be more a reflection of their driver writing ability then > anything inherent in accessing a device using the Windows driver. :-) > > As far as throughput is concerned, for changer devices it really isn't > relevant since the time taken by the robotics far exceeds any overhead from > the drivers. Not to mention that in the case of Bacula, and most UNIX > derived Backup software, an external program is executed to perform the > actual changer operations; so performance isn't really an issue. > > For tape devices, the only area where performance can be adjusted is in the > time required to setup the next write / read after the completion of the > current one. If you are using overlapped I/O and submitting multiple > requests concurrently to the driver then it can initiate the next request > without transitioning back to user mode and incurring a context switch. So > it would definitely perform much better than a user-mode application issuing > the SCSI commands. The driver also has access to constructs, like tagged > command queuing, that aren't available to the application. > > > I do not have experience running the Bacula sd on Windows, but I have > > run other enterprise backup systems on Windows and this was the advice I > > was given by the vendors. IIRC, the issue is with scsi device command > > communication, and the applications handled it better directly with the > > devices than through the Windows drivers. > > > > I suspect that the other Enterprise Backup vendors are basing their comments > on experience with Windows 9X as well as their experience with some Windows > NT drivers that may not have been written correctly. Also developers tend > to stick to what they know and the software was probably originally written > to send the commands directly. > > The only advantage with bypassing a well written Windows driver is access to > some SCSI facilities that may not be abstracted through the driver model > such as device and tape diagnostic information. > > > The earlier advice about determining the device id's using scsilist.exe > > would facilitate this, I think. > > > > The one thing you need to be careful of is that if there is a class driver > loaded, such as the tape class driver then you must send the SCSI commands > to it rather than to the physical address. > > > FWIW. > > > > > ------------------------------------------------------------------------- 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
