Date: Mon, 14 May 2018 04:57:04 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 228174] [dump] dump(8) can read garbage and loop forever Message-ID: <bug-228174-3630-O1pDv5FXOn@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-228174-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-228174-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D228174 --- Comment #3 from Kirk McKusick <mckusick@FreeBSD.org> --- Taking a snapshot is the same as if you unmounted the filesystem and dumped= it. When you take a snapshot, the following steps are taken: 1) Any new system calls that want to write to the filesystem are suspended. 2) All system calls currently writing to the filesystem are allowed to fini= sh. 3) All dirty blocks are flushed to the filesystem. 4) A snapshot of the fully flushed filesystem is taken. 5) The suspended system calls are awaken, but none of their changes appear = in the snapshot. The dump of the snapshot therefore gets a consistent view of the filesystem. The date of the snapshot is recorded, so that when you later take a level-1 dump (using another snapshot) you get exactlty the changes between the two snapshots. Putting in error checking for every possible inconsistency is a massive undertaking. And the resulting dumps are inconsistent and prone to all sort= of errors when you attempt to restore from them. That is why snapshots were ad= ded as they allow consistent and correct dumps to be made on a live system. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-228174-3630-O1pDv5FXOn>