>Number:         19711
>Category:       bin
>Synopsis:       dump write speed incorrect after a volume failure & retry
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jan 06 06:19:00 PST 2003
>Closed-Date:
>Last-Modified:
>Originator:     matthew green
>Release:        NetBSD 1.6K
>Organization:
people's front against (bozotic) www (softwar foundation)
>Environment:
	
	
System: NetBSD splode.eterna.com.au 1.6K NetBSD 1.6K (_splode_) #26: Sun Jan 5 02:48:50 EST 2003 mrg@what-time-is-love.eterna.com.au:/var/_splode_ sparc64
Architecture: sparc
Machine: sparc64
>Description:

	when dump(8) attempts to write a tape volume but gets a write error
	(eg, due to a remote tape filling up), and it asks if you want to 
	rewrite the volume, it appears to not re-set the volume start time.
	the effect is that after a failed write, the write speeds are typically
	much lower than they should be, and slowly rise up.  eg:

	  DUMP: Volume 4 transfer rate: 845 KB/s
	  DUMP: Change Volumes: Mount volume #5
	  [ .. ]
	  DUMP: write: Input/output error
	  DUMP: write error 727840 blocks into volume 5
	  DUMP: Do you want to restart?: ("yes" or "no") yes
	  DUMP: Closing this volume.  Prepare to restart with new media;
	  DUMP: this dump volume will be rewritten.
	  DUMP: Closing /dev/nrst0
	  DUMP: close: Input/output error
	  DUMP: Volume 5 completed at: Tue Jan  7 00:28:21 2003
	  DUMP: Volume 5 took 1:04:49
	  DUMP: Volume 5 transfer rate: 187 KB/s
	  DUMP: Is the new volume mounted and ready to go?: ("yes" or "no") yes
	  DUMP: Volume 5 started at: Mon Jan  6 23:23:32 2003
	  DUMP: Volume 5 begins with blocks from inode 6452301
	  DUMP: 86.90% done, finished in 2:10
	  DUMP: 87.44% done, finished in 2:05
	  load: 0.35  cmd: dump 7998 [pause] 0.46u 1.90s 0% 656k
	  87.70% done at 73 KB/s, finished in 2:02

	which is far less than the 800+ KB/sec that it really does...

>How-To-Repeat:

	write a large dump and fill your tape drive remotely, have dump complain
	and ask to rewrite it.  let it do this.  have the transfer rate now be
	wrong...

>Fix:
	looking at the code it seems that restarting a volume needs to reset
	tstart_volume ...
>Release-Note:
>Audit-Trail:
>Unformatted: