Apologies for resurrecting a 2.5-week old thread, but I've realised I ought to wrap up a few things before the [real:-)] millennium...
Chang-Ping Hu chang-ping.hu@netapp.com wrote: 1> 1> There are a few rationales behind the change. 1> 1> 1. To provide a fix to allow proper handling of a cleaning tape by DLT tape 1> libraries (Burt #29835.) 1> 1> 2. In the case of a stand-alone drive, to provide a consistent drive 1> behavior across various tape drive types. AIT and Exabyte drives will 1> physically eject a tape when an unload command is issued. This change will 1> make the DLT drives respond in a similar way, even though it does not 1> physically eject the tape. 1> 1> 3. The change will require a user to manually reload the tape to enable the 1> DLT drive to read it. This prevents accidentally overwriting a tape user 1> may otherwise think has been unloaded. Again, this is no different from the 1> AIT and Exabyte drives.
I think I'm convinced by the compatibility (2) and safety (3) arguments that the state before 5.3.7R2 was wrong.
1> In your particular case, to add incremental dumps, an alternative is to use 1> nrst0a instead urst0a. If you don't really care about the previous data 1> on the tape, you can even use rst0a.
and also Amol Chitre Amol.Chitre@netapp.com wrote 2> 2> In the absence of a stacker, why are you using a urst0a? It seems to me that 2> you are overwriting during the incremental dumps. In that case, you can use 2> a rst0a and the tape will not be unloaded. On the other hand, if you dont 2> want to overwrite, you can use nrst0a. In case you want to continue with 2> urst0a, you might have to do a manual unload and reload everytime.
I ought to have made this clearer. I use nrst0a exclusively for the dumps themselves, and pack several of them onto a single tape (these are small incremental dumps). There's an outer-level management script that checks labels, writes packing lists, and positions the tape, all via the na_rmt(8) interface [q.v.]. Dumps on successive days do not overwrite each other: they get added on the end of the tape.
At the moment, the management script ends up unloading the tape ("I6\n1\n" to na_rmt). Just opening the tape again the next day reloads it if the same tape is still sitting in the drive. This is convenient at times without operator cover.
Obviously I can change this to not unload the tape, but that has some disadvantages, including the greater exposure to loss of the filemark directory on a power failure that I mentioned before. I can live with it, though!
Solaris' rmt implementation supports some larger-numbered "I" (ioctl) operations beyond 6, including 14 (MTLOAD). A nice solution for me would be to have ONTAP's rmt support this as well: an explicit load request doesn't fall into the overwrite-the-tape-by-accident scenario. However, I suppose that these extensions are highly unstandardised, and it might be asking rather a lot of NetApp to support them.
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.