Backup Central

-----Original Message-----
From: Don MacArthur [mailto:macarthurd < at > cm...]
Sent: Thursday, March 15, 2007 7:27 AM
To: Robert Nelson
Cc: bacula-users < at > li...
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.

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:macarthurd < at > cm...]
Sent: Thursday, March 15, 2007 7:27 AM
To: Robert Nelson
Cc: bacula-users < at > li...
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.