Date: Tue, 23 Jul 2002 13:41:35 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Peter Jeremy <peter.jeremy@alcatel.com.au>, Andreas Koch <koch@eis.cs.tu-bs.de>, freebsd-stable@FreeBSD.ORG Subject: Re: 4.6-RC: Glacial speed of dump backups Message-ID: <20020723134135.A74781@panzer.kdm.org> In-Reply-To: <200207230425.g6N4PbuP057589@apollo.backplane.com>; from dillon@apollo.backplane.com on Mon, Jul 22, 2002 at 09:25:37PM -0700 References: <20020606204948.GA4540@ultra4.eis.cs.tu-bs.de> <20020722081614.E367@gsmx07.alcatel.com.au> <20020722100408.GP26095@ultra4.eis.cs.tu-bs.de> <200207221943.g6MJhIBX054785@apollo.backplane.com> <20020723131318.F38313@gsmx07.alcatel.com.au> <200207230425.g6N4PbuP057589@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 22, 2002 at 21:25:37 -0700, Matthew Dillon wrote: > :partitions more dangerous. (Since the cached data may not be relevant > :any longer). (Softupdate snapshots would help here, but they're not in > :-STABLE and I don't think Kirk's fixed a race-to-root deadlock yet). > :I suspect a cleaner (though much more effort) approach would be to > :make dump much chummier with the UFS code in the kernel so that it > :used the kernel FS buffer (with some hooks to prevent dump blowing > :the buffer cache for other processes). > : > :Peter > > Yes, the snapshot code will make dump useful again :-) I dislike the > complexity of the snapshot code, though. I'd rather see a solution > at the raw device level that, say, copies the original data into swap > when new data overwrites it for the duration of the snapshot. Or > something like that. Since the snapshot code is not likely to ever > be backported to -stable it's worth thinking about some sort of solution > for -stable. The Adaptec aac(4)-based controllers have board-level snapshot capability that works more or less like that. The command line interface for Unix doesn't have support for it, though. (that includes FreeBSD) The reason is that they couldn't find a good way to guarantee that the filesystem state is consistent before the snapshot is made. One problem that you may run into with doing snapshots at the raw device level instead of via the filesystem code is that there is more potential for filesystem inconsistencies. If UFS guarantees that things will always be consistent, or if dump checks to make sure everything is okay, then you'll probably be fine. Since that likely isn't the case, you'd really need some way to guarantee that the filesystem is fully synced out to disk and consistent, and then atomically create the snapshot without allowing any writes to creep in before the snapshot is created. The nice thing about the UFS snapshot stuff is that it (I assume) makes sure the filesystem snapshot is consistent. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020723134135.A74781>