Re: dump problems

From: Danny Braniss <danny_at_cs.huji.ac.il>
Date: Mon, 10 Sep 2007 11:14:45 +0300
> > > 
> > > 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
Received on Mon Sep 10 2007 - 06:14:47 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:17 UTC