Date: Thu, 18 Oct 2007 13:35:11 +0200 From: Danny Braniss <danny@cs.huji.ac.il> To: hackers@FreeBSD.org Cc: freebsd-current@FreeBSD.org Subject: Re: dump problems Message-ID: <E1IiTeh-0007tt-G6@cs1.cs.huji.ac.il> In-Reply-To: <E1IUePt-000P2R-RM@cs1.cs.huji.ac.il> References: <E1ISdQi-000GkC-4v@cs1.cs.huji.ac.il> <20070904233246.GA2409@epia-2.farid-hajji.net> <E1ISnig-000Nbm-Ep@cs1.cs.huji.ac.il> <043a01c7f202$a7ad0920$f7071b60$@co.uk> <E1IU10R-000MRT-T8@cs1.cs.huji.ac.il> <046801c7f229$a4534510$ecf9cf30$@co.uk> <E1IUcXc-000NdZ-LH@cs1.cs.huji.ac.il> <E1IUePt-000P2R-RM@cs1.cs.huji.ac.il>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > > > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1IiTeh-0007tt-G6>