> > > > > > 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 ...] dannyReceived 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