Date: Fri, 8 Feb 2002 11:01:17 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: "Duane H. Hesser" <dhh@androcles.com> Cc: Markus Stumpf <maex-freebsd-hackers@Space.Net>, freebsd-hackers@FreeBSD.ORG Subject: RE: dump(8) race conditions? Message-ID: <Pine.BSF.4.21.0202081057350.91961-100000@InterJet.elischer.org> In-Reply-To: <200202081855.g18ItgK66957@androcles.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 8 Feb 2002, Duane H. Hesser wrote: > > Dump is a two pass system, and any activity which modifies inodes > between the first pass and the second is likely to cause problems, > either for dump or for restore. It has always been thus, even as > far back as V7 (and probably v6). This is why you shouild use Kirk's new "snapshot" technology. it makes a frozen image of the filesystem that can be dumped. the snapshot file contains only metadata and data that id different between the current fs and as it was at snapshot time, so as the current filesystem changes, the snapshot file gets more and more 'diff' data put into it by the filesystem. > [...] > > It is operationally (and sometimes "politically") difficult to dump > on unmounted filesystems, so most of us (I think) "bite the bullet" > and try to dump at times when the subject filesystem is likely to > be quiescent. It may also be smart to dump more frequently than > otherwise called for, just to increase the odds. [find out about snapshots] it IS conceivable that snapshots might be retrofitted to 4.x, unlike some other 5.x features, because they depend on teh soft updates code which is already present. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0202081057350.91961-100000>