> > >
> > > 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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
