Date: Fri, 7 Apr 2000 16:38:10 -0500 From: "Jeffrey S. Sharp" <jss@subatomix.com> To: <freebsd-small@FreeBSD.ORG> Cc: "Jonathan M. Bresler" <jmb@hub.freebsd.org>, "Warner Losh" <imp@village.org>, "Adrian Steinmann" <ast@marabu.ch> Subject: Re: Mounting and Corruption Rehashed Message-ID: <00bb01bfa0d9$92a27150$2aa85c0a@vulcan> References: <20000404204324.3155E37B8D6@hub.freebsd.org> <200004042047.OAA70876@harmony.village.org> <200004061939.VAA08298@marabu.marabu.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
> When you remount / rread-write to update, just reboot and get on > with it (remounting ro works, but can we trust it?). I've done a similar hack by hand and it worked well. However, problems arise when changes have to be made often or when uptime requirements prohibit rebooting unless direly urgent. I have another possible solution to the flash problem: Use two partitions: one for /, kernel, and other static files that stays ro unless you are upgrading, and another for dynamic files that gets switched ro<-->rw. To detect any corruption, compare before-and-after checksums on the dynamic files. If corruption is detected, the partition can get newfs'ed, etc., and the have its files restored from somewhere else (a backup partition, maybe). Also, If you've got some custom application running, it might be prudent for it to keep its writes down by buffering data as long as possible. Or, someone could fix mount... [hint] =============================== Jeffrey S. Sharp (XorAxAx) jss@subatomix.com -----BEGIN GEEK CODE BLOCK----- Version 3.12 GCS/IT/MU d-@ s-:+ a21 C++(++++) UBL+(+++$)> P L+(+++$)> E+> W++ N+(++) o? K? w++$> !O M(-) !V PS+ PE Y PGP- t+ 5 X+ R(+) tv+ b+ DI++(+++) G++ e> h--- r+++ y+++ ------END GEEK CODE BLOCK------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00bb01bfa0d9$92a27150$2aa85c0a>