Re: [Networker] Networker behavior relabeling medium ...

Think about how you would recover from a failure.

What if the system loses power after the tape is labeled but before anything 
else is done? How
do you recover? How confused does NetWorker get?

Yes, your design change will prevent the stupidity caused loss of the media 
information from
happening, but it opens up a whole new avenue for NetWorker to become terribly 
corrupted.

With the current failure scenario, you can use scanner to recover the contents 
of that tape.
What do you do when you've overwritten the label but NetWorker still thinks 
there are savesets
on the media? Do you even see that error until later when someone tries to 
recover a file or
when NetWorker goes to write more data to that tape?

I don't see your new design as an improvement at all.

Frank

On 6/24/11 3:54 AM, Thierry Faidherbe wrote:
> All,
>
>  
>
> More than once, we all have been faced to operators loading
>
> write-protected tapes into library. In other cases, we may have
>
> also voluntary loaded write-protected tapes into libs 
>
> wrongly thinking networker will not overwrite recyclable tape 
>
> to preserve its contents…
>
>  
>
> >From my experience, I think networker logic recycling/relabeling
>
> medium is:
>
>  
>
>       Load targeted medium into drive
>
>       Verify its label
>
>       if (tape label is expected one)
>
>       then
>
>             Purge all SSID from MediaDB,
>
>             Case 
>
>               relabel : Delete MediaDB Tape Record
>
>               recycle : Update MediaDB Tape Record 
>
>             Write new label
>
>             Verify it
>
>             Case 
>
>               recycle : I update MediaDB Tape Record with tape cycle usage
>
>       done
>
>  
>
> If the medium is write protected, label write operation will fail
>
> but all media infos are already purged from MediaDB.
>
> It will also result in tapes being stored in our libs but not
>
> belonging to any pool.
>
>  
>
> Am I wrong thinking it’s time to update above logic, only purging/updating
>
> MediaDB only if label operation succeeded ? Should not be too complex
>
> to update code, I think.
>
>  
>
> So, if media cannot be overwritten (nor recycled nor relabeled),
>
> networker could track volume to not be writable from its lib maps 
>
> and not looping trying to recycle same volume.
>
>  
>
> Any other ideas about ? RFE ?
>
>  
>
> Cheers
>
>  
>
> Th
>
>  
>
> Kind regards - Bien cordialement - Vriendelijke groeten,
>
>  
>
> Thierry FAIDHERBE
>
> Backup/Storage & System Management
>
>  
>
> LE FOREM
>
> Département des Systèmes d'Information
>
> Direction Infrastructure
>
>  
>
> Boulevard Tirou, 104  Tel:    +32 (0)71/206730
>
> B-6000 CHARLEROI      Mobile: +32 (477)/995319
>
>                       Fax:    +32 (0)71/206199 
>
> BELGIUM               Mail : Thierry.faidherbe<at>forem.be
>
>  
>
>
> To sign off this list, send email to listserv AT listserv.temple DOT edu and 
> type "signoff networker" in the body of the email. Please write to 
> networker-request AT listserv.temple DOT edu if you have any problems with 
> this list. You can access the archives at 
> http://listserv.temple.edu/archives/networker.html or
> via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

-- 
Frank Swasey                    | http://www.uvm.edu/~fcs
Sr Systems Administrator        | Always remember: You are UNIQUE,
University of Vermont           |    just like everyone else.
  "I am not young enough to know everything." - Oscar Wilde (1854-1900)

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER