[Gllug] flushing tape drive cache - SOLVED

[Ryan Cartwright]

Hi all,

-- egg on face - long explanation follows ---

further to my earlier post - the drive cache was not the problem - the 
symlink was.

* The drive is an ATAPI drive and it is the first IDE/ATA device
* /dev/tape is symlinked to /dev/hda
* `ls -lh /dev/hda` revealed this..

-rw-r--r--    1 root     root          43G 2006-03-25 01:32 /dev/hda

note the lack of the c at the front there - or indeed the device 
numbers. This is a local file and not a device at all....all my backups 
have been going to a local file and not to a tape (which I have been 
carrying around in my bag!!!!). We hadn't spotted this because whenever 
we retrieved a file it was from last night's backup and thus the file 
/dev/hda was able to deliver the file we wanted to retrieve. We 
bascially only noticed this because we were retrieving a file someone 
deleted on Friday and they wanted it back from Thursday's backup. 
(fortunately they had mailed someone else a copy for comments and got it 
back from them!).

One of the other servers running here (which is running correctly) has 
the ide-tape module loaded which presents the ide tape drive as /dev/ht0 
and `ls -lh /dev/ht0` gives

crw-------    1 root     root      37,   0 2003-10-02 21:45 /dev/ht0

Thus `mt -f /dev/tape status` on *that* machine gives the status of the 
tape drive (/dev/tape symlinks to /dev/ht0 on there).

thanks for the suggestions anyway. I currently have people checking the 
other servers (not many) for the same or similar setup errors.

Ryan
BTW - if anyone is interested mt does have a drvbuffer option which 
works on SCSI drives.

`mt -f <device> drvbuffer 0` switches off the drive's buffer and 1 will 
switch it on again.

Not that it would have helped me in this case as it's an ATAPI drive.
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug