danny at cs.huji.ac.il
Thu Oct 18 05:01:45 PDT 2007
> > > >
> > > > 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
> so here are some questions:
> - is the readers/writer split realy needed now? my guess it was put in in the
> days to get tapes streaming - which is btw, what's not working.
> - is it/will it be needed for ZFS? [dump is for ufs ...]
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.
More information about the freebsd-hackers