Date: Wed, 14 Oct 1998 11:08:05 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: Terry Lambert <tlambert@primenet.com>, Don.Lewis@tsc.tdk.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching Message-ID: <Pine.BSF.3.95.981014105142.2872Q-100000@current1.whistle.com> In-Reply-To: <199810140518.XAA15040@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hey everybody.. look, we're in violent agreement here but haven't noticed it.... 1/ Soft updates produces a consistent view of the filesystem at the level where reported completions are generated. 2/ If there is another layer below that (a write cache) then if the transactions are re-ordered in that layer, then lower layers may not get a consistent view of the filesystem at every instant. 3/ Given time and power, the layer that generates the completion reports will sync down to the lower layers making them consistent. Lack of either will have the lower layers in an inconsitent state. 4/ Drives that do not sync down after there is a scsi reset are in danger of producing corrupted filesystems after a warm reboot. This should be considered a firmware bug. 5/ Systems that run without UPS, or want to be able to withstand more drastic failures (e.g. PSU explodes) should run without write caching, or should ensure that writes to media occur in the same order as completions are generated (not neccesarily the same as write requests as they could be re-ordered before the completions are issued). Since the latter is unlikely, the former is preferable. 6/ Since Softupdates makes all writes asychronous, the penalty for turning off write caching is very minimal. My experiments show a 1% difference in normal operation. THere are some applications however where this is not true, and these application should not consider soft updates alone to be a guarantee of FS consitency. They should have some way of guaranteeing 'time and power' (and good firmware). 7/ to allow for this to be achieved easily, there should be an easy way to ensure that the write cache is turned off. Possibly as simple as a good example in camctl.8 . julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.981014105142.2872Q-100000>