Date: Fri, 26 Jul 2002 06:51:29 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: "Mark W. Krentel" <krentel@dreamscape.com>, freebsd-stable@FreeBSD.ORG Subject: Re: 4.6-RC: Glacial speed of dump backups Message-ID: <20020726065129.Q38313@gsmx07.alcatel.com.au> In-Reply-To: <200207240513.g6O5Dljx025899@apollo.backplane.com>; from dillon@apollo.backplane.com on Tue, Jul 23, 2002 at 10:13:47PM -0700 References: <200207240505.g6O550534455@dreamscape.com> <200207240513.g6O5Dljx025899@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2002-Jul-23 22:13:47 -0700, Matthew Dillon <dillon@apollo.backplane.com> wrote: > Now FreeBSD's dump program does in fact do a sync() itself, > right in its main(). This is probably why you didn't see the > problem w/ FreeBSD. If FreeBSD's dump program did not do that > sync() your test would probably not have worked. > > If linux's sync() does not sync the filesystem then it's a bug in > linux's sync(). Tradionally, sync(2) just initiates the cache flush, it does not block until the flush completes (hence the "type sync 3 times on your KSR33 before halting" mantra). This is even documented under BUGS in our sync(2) man page. Our dump(8) does a sync() and then carries right on merrily. There's nothing ensuring that the cache is completely flushed. Since the first few dump passes relate to metadata (which is traditionally updated synchronously) its highly unlikely that the cache flush won't have completed by the time dump gets around to dumping the actual data. For both soft updates and async mounts, it would seem a bit of a gamble since the metadata may not be flushed before dump gets around to looking at it. (And softupdates guarantees that the disk is consistent at a point in time, it doesn't guarantee that an inode read now is consistent with a data block read 30 minutes later). That said, Mark's problem suggests that a dirty data block isn't being flushed - which does look more like a cache flush bug. Peter 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?20020726065129.Q38313>