Re: dump problems

> > > > 
> > > > the only indication I can see, is that one of the dump procs. is
> > > > waiting on
> > > > sbwait, and probably it's some deadlock, which is similar to what I
> > > > keep
> > > > seeing here, i'll try now with SCHED_ULE to see if it make a
> > > > difference.
> > > 
> > > 
> > > I'm running SCHED_ULE on these already, if your not I guess it's not the
> > > scheduler?
> > > 
> > I can get it to 'work' by fiddling with the b flag (blocksize), which still
> > points to some timming/deadlock problem.
> > ie:
> > 	dump 0abf 64 /some/backup/file  /file/to/backup
> > now works, but
> > 	dump 0abf 64 - | restore rbf 64 - 
> > hangs as before. (i don't think the b 64 in restore is needed).
> 
> ok, it is time to look at the sources, this program has been around since the 
> beginin of time,
> or at least since Unix V6 :-), and it has been hacked ever since. but now that
> most of you never heard of 9track tapes, etc, I was wondering if there is a 
> point in hacking at
> it again. 
> pros: dump/restore has never failed me till now.
> cons: there are other programs tar/cpio/gtar/etc, but they each have their 
> nits.
> so here are some questions:
> 	- is the readers/writer split realy needed now? my guess it was put in in the 
> old
> 	  days to get tapes streaming - which is btw, what's not working.
> 	- is it/will it be needed for ZFS? [dump is for ufs ...]
> 
> danny

Assumption:
  Since dump was written, much has changed, and in the days of single-core/UP 
the Caltech hack
  (see /usr/src/sbin/dump/tape.c) works. On newer multicore hardware it will 
enter into deadlock
  and thus hang, specially if 'tape' is a file or pipe.

While I'm now putting on the surgical cap to dissect tape.c, any further 
insight is welcome.

cheers,
	danny