Date: Mon, 26 Jul 2004 12:54:39 -0600 (MDT) From: Scott Long <scottl@freebsd.org> To: Brian Fundakowski Feldman <green@freebsd.org> Cc: bugghy <bugghy@home.ro> Subject: Re: magic sysrq keys functionality Message-ID: <20040726125328.L32601@pooker.samsco.org> In-Reply-To: <20040726181821.GB96815@green.homeunix.org> References: <1090718450.2020.4.camel@illusion.com> <200407251112.46183.doconnor@gsoft.com.au> <20040726152151.GC1473@green.homeunix.org> <20040726175219.GA96815@green.homeunix.org> <20040726181821.GB96815@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 26 Jul 2004, Brian Fundakowski Feldman wrote: > On Mon, Jul 26, 2004 at 12:15:02PM -0600, Scott Long wrote: > > On Mon, 26 Jul 2004, Brian Fundakowski Feldman wrote: > > > On Mon, Jul 26, 2004 at 11:49:55AM -0600, Scott Long wrote: > > > > On Mon, 26 Jul 2004, Brian Fundakowski Feldman wrote: > > > > B> On Sun, Jul 25, 2004 at 09:23:36PM +0000, bugghy wrote: > > > > > > Yeah but it sometimes "freezes" (no reboot) ... and I'd rather umount my > > > > > > filesystems before rebooting. > > > > > > > > > > SoftUpdates guarantess that your file systems will not get corrupt. > > > > > > > > > > > > > This isn't entirely correct. Softupdates guarantees that you won't get > > > > corruption due to metadata pointing to invalid or stale data blocks. > > > > That's not the same as guaranteeing that there won't be any corruption. > > > > Write caching on the drive combined with an in-opportune power loss or > > > > other failure can easily leave you with corrupt or incomplete metadata > > > > and/or data blocks. A panic while metadata is being committed to disk can > > > > also leave the metadata highly inconsistent and prone to corruption. > > > > This isn't to say the SU is bad or that other strategies are necessarily > > > > better, just that there are definite risks. > > > > > > If you just want to generalize it, you can say that "SoftUpdates > > > guarantees that your file systems will not get corrupt due to just > > > software errors." I don't particularly think not having UPS is a > > > good idea, but those can fail, and even so the ordering is such > > > that a truncated inode won't result in a truly corrupt filesystem, > > > and the inode doesn't get written until its contents are written > > > out. > > > > > > Also, hw.ata.wc really shouldn't default to 1. > > > > > > > GAH! No, please don't start this war again! The last time that we tried > > turning this off in a release (4.1 IIRC), were were plagqued by months of > > earthquakes, plagues, and deaths of first-born youngsters. I 100% agree > > that write caching in ATA is not compatible with data integrety, but the > > ATA marketting machine has convinced us that cached+untagged speed is > > better than uncached+tagged safety. C'est la vie, or so they say here. > > I think it would be prudent to add a nice fat "WARNING:" printf to the > boot process. It's really not obvious that FreeBSD defaults to having > your hard drives run "unsafely," even though it is usually faster. > I think that this was discussed too. The problem is that Linux and Windows also silently default to having it on, and breaking from that status quo causes too much haertburn. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040726125328.L32601>