Date: Thu, 7 Feb 2002 19:08:49 +0100 From: Markus Stumpf <maex-freebsd-hackers@Space.Net> To: Dan Nelson <dnelson@allantgroup.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: dump(8) race conditions? Message-ID: <20020207190849.B87994@Space.Net> In-Reply-To: <20020207175402.GA79258@dan.emsphone.com>; from dnelson@allantgroup.com on Thu, Feb 07, 2002 at 11:54:02AM -0600 References: <20020207185052.A87994@Space.Net> <20020207175402.GA79258@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 07, 2002 at 11:54:02AM -0600, Dan Nelson wrote: > Dump should ideally be run on an unmounted filesystem. The next best > is to create a snapshot ( /usr/src/sys/ufs/ffs/README.snapshot ) and > dump that. True. But on systems that host e.g. mailservers or webservers its unacceptable to disrupt services tp umount and backup the system :/ $ uname -a FreeBSD 4.4-RELEASE $ more /usr/src/sys/ufs/ffs/README.snapshot /usr/src/sys/ufs/ffs/README.snapshot: No such file or directory :-))) Located it in stable, but the READNE says: 2) Run dump on the snapshot. You will get a dump that is consistent with the filesystem as of the timestamp of the snapshot. Note that I have not yet changed dump to set the dumpdates file correctly, so do not use this feature in production until that fix is made. :-(( Anyway, I have no problem with the errors per se, just wanted to know if they could result from the race conditions or if I have to better change the disks. \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin" 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?20020207190849.B87994>