Bug 20501 - [patch] dump(8) extra flag to dump to offline autoloaders at EOT
Summary: [patch] dump(8) extra flag to dump to offline autoloaders at EOT
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 3.5-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2000-08-09 12:10 UTC by ip
Modified: 2017-12-31 22:37 UTC (History)
0 users

See Also:


Attachments
file.diff (2.87 KB, patch)
2000-08-09 12:10 UTC, ip
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description ip 2000-08-09 12:10:01 UTC
Solaris has an additional ("l") flag to dump (aka ufsdump) which offlines
a tape drive after EOT is detected. This tells DAT autoloaders which are
in manual mode (i.e. the changer LUN hasn't seen any commands since the
pod was loaded) to unload the current tape and load the next, if possible.
The dump then continues without manual intervention until all tapes are
written.

The code is pretty simple. When EOT is reached, and we've waited for the tape
to rewind, we do an OFFLINE ioctl and then wait again for two minutes or so
until the tape opens successfully. If it doesn't, we assume we've used all
the tapes in the pod and ask for manual intervention as before.

Similar patches applied to FreeBSD 4.1-STABLE and NetBSD/SPARC 1.4.1.
Comment 1 mjacob 2000-08-09 16:56:35 UTC
Why don't you just use the 'eject on close' tape device?
Comment 2 ip 2000-08-09 17:12:33 UTC
Hi Matt,

> Why don't you just use the 'eject on close' tape device?

First thought: doh... didn't know there was one... can't find it in the
mtio manpage.

But I'd still need to tell dump to proceed. Doing it this way means I can
write an entire pod without manual intervention. 

Cheers,

Ian.
-- 
     Network Unit, Manchester Computing, The University, Manchester, UK.
     mail: ip@mcc.ac.uk | phone: +44-161-275-6006 | fax: +44-161-275-6040
	     "Europe's Premier Research Supercomputing Facility"
           Another android exhibiting signs of the Munich Syndrome.
Comment 3 mjacob 2000-08-09 17:21:53 UTC
'sa(4)' man page

I see your point, but if you're going to use dump, this method only works for
stackers. It'd be better if you swiped amanda's perl script which also can
then work with real changers using chio, no?
Comment 4 Matt Jacob freebsd_committer 2001-10-02 06:36:42 UTC
Responsible Changed
From-To: freebsd-bugs->mjacob

I'll look at it.
Comment 5 Mark Linimon freebsd_committer freebsd_triage 2004-08-26 03:36:17 UTC
State Changed
From-To: open->feedback

With bugmeister hat on, reassign from inactive committer. 


Comment 6 Mark Linimon freebsd_committer freebsd_triage 2004-08-26 03:36:17 UTC
Responsible Changed
From-To: mjacob->freebsd-bugs

Is this still a problem with modern versions of FreeBSD?
Comment 7 Mark Linimon freebsd_committer freebsd_triage 2004-08-26 07:06:04 UTC
Responsible Changed
From-To: freebsd-bugs->mjacob

mjacob has reactived his commit bit.  mea culpa for the bogus reassignment.
Comment 8 Mark Linimon freebsd_committer freebsd_triage 2004-08-26 20:16:01 UTC
State Changed
From-To: feedback->open

Feedback received. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=20501 

Adding to audit trail from personal email recevied 07/04/2005 as a
side-effect of some old email being reposted:

I'm not quite sure why this reappeared in my mailbox. I've had a few people ask
me for the patch over the years, including one guy who wanted it to work with
rmt for remote drives -- it'll need tweaking for $OSVER > 4.11. I'd assumed
this PR was forgotten about.

AFAIK, modern versions of FreeBSD still don't do this, but I don't have a
-CURRENT box right now, just 5.4. But the DAT autoloaders are no longer in
use, so its not a problem (for me).

Cheers,
Comment 9 Mark Linimon freebsd_committer freebsd_triage 2007-08-04 13:11:22 UTC
Responsible Changed
From-To: mjacob->freebsd-bugs

Assignee has turned in his commit bit, so return to pool.
Comment 10 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:50 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped