[Rear-users] Backing up to tape-drive and OBDR

Gratien D'haese gratien.dhaese at it3.be
Tue Aug 24 20:40:06 CEST 2010


On 24 Aug 2010, at 15:52, Dag Wieers wrote:

> On Mon, 23 Aug 2010, Gratien D'haese wrote:
> 
>> nice to hear from you again, and busy with the OBDR part (for rear) I see - excellent.
>> Well, perhaps, not an useful url for you: http://h18006.www1.hp.com/products/storageworks/drs/qa.html
>> but it might give you some other thoughts (doubtful :)
>> 
>> ok, the purpose of OBDR is that you put the tape drive in ISO mode (by pressing the eject button and recycle the damn HW).
>> However, you experience that you load the initrd image from the 
>> emulated ISO image (on tape) and that the tape drive does't go into a 
>> soft-reset cycle required to have a normal tape drive again after 
>> loading the initrd&kernel (so far nothing you didn't know yet /)
> 
>> First of all, congratulations as this was the though part!
> 
> According to the tape drive documentation, the drive automatically goes 
> into Tape-drive mode after a Logical Unit reset (or a hard reset) and 
> reading at least 100 blocks from the ISO. (Unless No-Auto mode is 
> activated, which is not the case)
> 
> Which doesn't seem to happen in our case. In fact we tried to do that 
> manually afterwards (send a device reset and then read 100 blocks) and it 
> doesn't work as documented.

what kind of hardware are you using? First time I hear about 100 blocks, I can make an ISO image go beyond 100 blocks I guess.

> 
> 
>> In the past (read mkcdrec) a small initrd was loaded (to find a cdrom) 
>> and then the bigger ramdisk was loaded into memory followed by a soft 
>> switch of the root which brought the tape ISO emulation into normal tape 
>> mode again.
> 
> We don't understand how a switch_root or pivot_root could disable OBDR and 
> bring back the tape device. This piece is missing from what we can see,
> unless the drive automatically/correctly switches to tape-drive mode 
> after reading 100 blocks as the manual states, which it does not seem to 
> do in our case. And even then you still have to rescan the controller 
> (only an rmmod cciss, and modprobe cciss seems to work).

is the tape controller also the cciss?

> 
> 
>> I think the procedure could be the following (#host #channel #id #lun 
>> should be replaced of course)
>> 
>> 1) power cycle tape drive
>> 2) from another shell (Alt+F2)
>>  - echo "scsi remove-single-device 1 0 3 0" > /proc/scsi/scsi
>>  - modprobe st

in mu humble opinion modprobe st is the key for geting the tape device into normal mode again, but yeah I was using (>5 yrs ago) simple DDS4 tape drives.

>>  - echo "scsi add-single-device 1 0 3 0" > / proc/scsi/scsi
>>  to reconfigure the tape drive in Sequencial-Access mode
>> 
>> # cat /proc/scsi/scsi:
>> Host: scsi1 Channel: 00 Id: 03 Lun: 00
>> Vendor: HP       Model: C7438A           Rev: ZP76
>> Type:   Sequential-Access                ANSI SCSI revision: 03
>> 
>> This could be done via a special function of script to release the 
>> OBDR_mode again. I would hate to see that a 2th screen is required...
> 
> This unfortunately does not work. In fact the only reliable way we found 
> to switch off OBDR mode of the tape-drive (thanks to Jeroen Hoekx !) is to 
> use a tape-device specific MODE SELECT. For the tape device we have here, 
> the following command performs the MODE SELECT:
> 
> 	sg_wr_mode -f -p 3eh -c 3e,2,0,0 /dev/sg1
> 
> After that we are forced to unload the cciss module and reload it again. 
> But we don't want to fall back on using sg3_utils and/or drive-specific 
> functionality. We are looking now at sending a Reboot firmware command 
> instead.
> 
> Some other things we learned (unfortunately the hard way) is:
> 
>  - You won't have a tape-drive or virtual cdrom if you don't perform a
>    "scsi engage" towards the CCISS controller. Rear does not pick up the
>    necessary script for doing this. We are looking at using udev to
>    perform this "scsi engage" on the fly (if that is at all possible).

if you want udev then switch to the beta code 1.9.0 which is in SVN trunk. It works pretty well already,
but we're adding patches to it (and evaluate correctness etc..). So, it will still sit in the trunk for a while
before we release 1.9.0 officially.
My best guess is you better switch to this code before continuing with the tape handling...
> 
>  - Enabling OBDR mode with a tape that is not rewound, fails horribly in
>    all respects. When it eventually boots (ejecting the tape continuously)
>    you don't have a virtual cdrom or tape-drive. A reboot and explicitly
>    disabling OBDR is the only option. Then rewind, then do it all over
>    again.

from old code (mkcdrec):
echo "OBDR: positioning the tape..." 
mt -f ${TAPE_DEV} rewind
mt -f ${TAPE_DEV} fsf 2
echo "OBDR: reading ram disk image into /dev/ram1 or /dev/rd/1"
if [ -b /dev/ram1 ]; then
ROOT_DEV=/dev/ram1
dd if=${TAPE_DEV} | bzip2 -dc > /dev/ram1 

make sure that the iso image has dd, mt and kernel module st on board... and always use the no-rewinding tape device. 
Will avoid lots of problems.

> 
>  - When you enable OBDR through the controller, the tape-drive becomes
>    horribly slow the next OBDR-less reboot. The only option is to do a
>    subsequent reboot.
> 
> Any advice/experience would be helpful :-)
I'm afraid my advise is limited in your case - seems a combinations of little issues...

> -- 
> --   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
> [Any errors in spelling, tact or fact are transmission errors]
> 





More information about the rear-users mailing list