Date: Sun, 18 Jan 2004 21:48:54 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk>, Randy Bush <randy@psg.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: rewinding a disk drive takes too long Message-ID: <p06020478bc30f510ed24@[128.113.24.47]> In-Reply-To: <77605.1074377612@critter.freebsd.dk> References: <77605.1074377612@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
At 11:13 PM +0100 1/17/04, Poul-Henning Kamp wrote: >In message <E1Ahyej-0000OI-5l@psg.com>, Randy Bush writes: > > >>btw, what i forgot to say was >> o source system is current as of yesterday >> o dest system is stable as of today > > o until the last upgrade to the stable dest, dump would > > never complete! it always got to the same point, 86%, > > and then hung > >This is actually a pretty normal thing, dump is not very good at >predicting the size of a dump if the filesystem is live (and I >belive in a few other circumstances as well) > >Largest number I've seen recently was -250% :-) Why would dump have trouble predicting the size of a "L" filesystem? If "L" is specified (and it apparently was in this example), then wouldn't dump be working off of a static snapshot of the filesystem? -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p06020478bc30f510ed24>