CDI is extended SCSI commands for your device. You should get "better"/improved information from the device etc.

By turning it off you probably get a little less descripting error/information from you device.

Have never seen any performance issues when turning it off. Not all platforms support CDI, HP-UX for example.

Run HP-UX, so we run w.o. it. (Using target from a F.S VTL as you do.)

Haven't run R.H. for a while but it seems like you have a SAN/SCSI ordering issue.

On HP-UX we have to delete the /tmp/lgto_scsi_devlist and then run inquire.

After that we use the NMC to add drives to our VTL.

Guessing a bit here, but when you turn off CDI, you limit networker to use the "plain" target adress(/dev/nst3) instead of

querying the device for the WWN and compare it to your current configdb.

Best regards

Håkan Engman

The Common Device Interface (CDI) media analysis tool was introduced in 2001 with NetWorker release 7.0 to provide a generic passthrough solution across all operating systems for the purposes of tape control and status collection, without depending on the implicit operating system driver mechanisms and without getting in the way of "Read/Write" operations of the devices.

CDI is a newer industry-wide method of talking to drive compared to old-style magnetic tape input/output.

In the past, there were a lot of reports of CDI causing problems and thus it was frequently disabled. In all cases, it was due to faulty tape drive device drivers that did not perform well when SCSI pass-through commands were passed to it.

In cases where appropriate device drivers are in use, please enable CDI (set it to “SCSI commands”) as it allows NetWorker to use more advanced interface when communicating with tape devices. Usage of CDI is standard in both device tests and Reliability and Availability tests performed by EMC Quality Assurance. It has also been successfully tested with Virtual Tape Library systems.

File-type devices (both FTD and AFTD) in NetWorker do not use CDI.

Can we get an idea of what version of NetWorker your running, what are your Storage Nodes, etc...?

I would also like to suggest you contact Support, if you have not already. If this turns out to be a new case of CDI not working with an OS (RHEL 5.1) changes we need to know so we can troubleshoot and fix or update out Support and perhaps even some tech notes.

Thanks Stephan!

-Steve

We useNetworker 7.4.4 our Backup Server is a Red Hat 3 Server.

Befor Yesterday the CDI was on all Drives on "SCSI Commands" and it worked normal.
Then we upgrade one of our two Falconstor VTL from RH4 with VTL Software 4.0 to RH5.1 with VTL Software 5.1

I think the problem is that VTL Software 4.0 support CDI so it worked normal with CDI on"SCSI Commands" now with VTL Software 5.1 it didnt work so i think this Version didnt Support CDI anylonger. I Check that with Falconstor.

But the Strange part is the Windows Stages that have there Drives from this VTL worked normal WITH "CDI on SCSI Commands" the Linux and Solaris didnt worked.

Thanks
Stephan

Check and let us know the drivers and versions of those that you, or FS, are using for the drives. IBM LTO-3 drive emulations correct?

We Simulate HP LTO3 with FW G27D at the VTL

scsidev@8.0.0:HP      Ultrium 3-SCSI  G27D|Tape, \\.\Tape0
                                           S/N: 8AU5S0020K
                                           ATNN=HP      Ultrium 3-SCSI  8AU5S0020K
                                           WWNN=50063032304BAAAA
                                           WW2N=50060B000029AAAA

We use the following driver:

Windows:                HP StorageWorks Driver 1.4.0.0 from HP (we have HP Server)

Red Hat Linux:         It is the Red Hat Driver that came with the OS

Solaris:                    Thes same as Linux

Solaris 9

Patch ID 113277 references Solaris generic st (SCSI tape) kernel module.

Minimum required version is -35.

Note that as this patch also includes sd (SCSI disk) kernel module, therefore a reboot is required upon installation

Solaris 10

The minimum revision of SCSI tape kernel module included in Solaris 10 has native LTO support. No additional patches are required. w Library connectivity on Solaris 10 the Solaris SCSI generic (sgen) interface is used. As a result, NetWorker low-level SCSI jukebox commands (sji) cannot be used while the library is configured and enabled in NetWorker.

Linux

Linux st kernel module does have native LTO support by utilizing its generic functionalities, but some of the default settings are known to cause problems. The appropriate entries must be added to /etc/stinit.def file and devices initialized with stinit command. For examples of these entries please contact your EMC account TC and have them send me a mail if they do not already have the necessary information.

I am working on cretaing a documant we can share publicly for this but in the meantime please have your EMC rep contact me or Support and we can point them to the proper information.

Hope this is helpful...

-Steve

Hi Steven

Thanks for your help.

I think the Problem is with the Falconstor VTL.

We run Networker with CDi on for Years no problem. Then we Upgrade the VTL from Version 4.0 to 5.1 since then we had problem with CDi on.

Yesterday we upgrade the Second VTL to 5.1 exactly the same problem. Bevor the Upgrade CDI on no problem after the Upgrade we had to disable CDI.

I open a Ticket at Falconstor. Maybe they didnt support CDI anymore with Version 5.1

Stephan

Thank you Stephan. Please do keep us posted so that we can update our Support folks as well.

Cheers!

Steve

Hi

The Problem is solved.

Falconstor told me to delete alle Librarys in the VTL and Networker and confige it new.

I didnt do that. What i did is configering a new Test Library. With the new Library CDi worked normal.

It looks like that after the Upgrade from Falconstor VTL 4.0 to 5.1 the VTl hade some problem with CDi. it can be solfed with deleting and new configuration of all VTl Librarys.

But i dont do that. becouse the Backup runs sins 2 Month ithout CDi and we had no problems.

Thnks for all who helped me.

Stephan

The issue you are having is due to the change on the FalconStor.

Devices on a SAN have device identifiers associated with them. These include the WorldWide Name (WWN) WorldWide Port Name (WWPN) and serial number (SN). NetWorker stores this information when it has talked to a drive to help prevent against a drive being discovered in the incorrect order by the operating system.

Device ordering is not guaranteed consistent in most operating systems unless you enable persistent binding at the HBA or driver level (see udev on Linux). To help guard against this, NetWorker had stored the WWN of the older drive, and when you upgraded, it changed all the device identifiers. The message below is telling you exactly that.

Nov 11 09:57:14 bwbckse1zhh logger: NetWorker media: (alert) device "/dev/nst3": serial number mismatch, check system device ordering. Expected "Serial Numbers:WWNN=500630323142AAAA:ATNN=HP      Ultrium 3-SCSI  8AU5S0021B:8AU5S0021B", found ":WWNN=4850202020202020:8AU6400238"

The Serial Number was this prior to the upgrade of the FalconStor:

Serial Numbers:WWNN=500630323142AAAA:ATNN=HP      Ultrium 3-SCSI  8AU5S0021B:8AU5S0021B

it is now

WWNN=4850202020202020:8AU6400238"

which is different, and so NetWorker is not wanting to use a device which does not appear to be correct. You should be able to clear this value from the device resource and the next time you utilize the drive it will store the new value. CDI is a good thing to have on in your environment since it allows for extended sense data from the drives and also allows you to do SCSI reserve which helps guard against rogue SCSI resets.

Scott