Date: Mon, 22 Feb 2010 15:10:01 +0000 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Jerry McAllister <jerrymc@msu.edu> Cc: Aiza <aiza21@comclark.com>, freebsd-questions <questions@freebsd.org> Subject: Re: Dump questions Message-ID: <4B829E49.3050202@infracaninophile.co.uk> In-Reply-To: <20100222143028.GA43687@gizmo.acns.msu.edu> References: <4B80ABBA.9000707@comclark.com> <20100221110358.9ec8b286.freebsd@edvax.de> <20100222030127.GA41439@gizmo.acns.msu.edu> <4B8206AE.8080105@comclark.com> <20100222143028.GA43687@gizmo.acns.msu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 22/02/2010 14:30, Jerry McAllister wrote:
> No. In multi-user, files are still changing. The snapshot could
> possibly be made between parts of a change - between different writes
> to the file, so there could be some inconsistency. In practice this
> is not a big problem, but, single user with filesystems unmounted is
> still the most absolute way of making sure a filesystem is quiescent
> during a dump.
Umm.... you don't *need* to go to single user to ensure a consistent
filesystem dump: unmounting the partition is sufficient, or remounting
it read-only. It's just that shutting the system down and rebooting to
single user mode can save you a deal of faffing about trying to kill
off any processes still using the filesystem, which would otherwise
block your ability to unmount it.
Note too, it's *reboot* into single user ('shutdown -r now', then press
4 at the boot menu) not *drop* into single user ('shutdown now') which
doesn't unmount filesystems for you, although it should kill almost all
processes.
Single user has it's own disadvantages: generally there's no network
configured, and with the root partition mounted read-only, you can't
update /etc/dumpdates.
Whenever you boot into single user, remember to run 'fsck -p' to ensure
filesystem integrity. I'm not sure what happens if you attempt to
dump'n'restore a dirty filesystem, but it's certainly going to have
unintended consequences if the filesystem is actually damaged rather
than just dirty.
Cheers,
Matthew
- --
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuCnkkACgkQ8Mjk52CukIyR+gCfX9rep9S9DQcIcRDqSoAptQX9
gMkAoIV/zhe4kRRlRN8fjn5+W7CS1csM
=6J2U
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B829E49.3050202>