Date: Tue, 13 Oct 1998 23:11:41 -0600 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Terry Lambert <tlambert@primenet.com> Cc: gibbs@plutotech.com (Justin T. Gibbs), Don.Lewis@tsc.tdk.com, julian@whistle.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching Message-ID: <199810140518.XAA15040@pluto.plutotech.com> In-Reply-To: Your message of "Wed, 14 Oct 1998 00:49:31 -0000." <199810140049.RAA20004@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> >It doesn't, since "# of anomalies == 0" with write caching disabled. >> >> This doesn't follow. If the cache is disabled, it doesn't matter if >> the drive loses power due to hitting the reset button. We already >> know that losing power on a drive that cached data will not work. > >We do? Of course we do. Why do you think my position on this subject has always been, "Write caching is fine so long as you use a UPS"? >If writes are committed in dependency order, and the write is cached >and there is no reordering of subsequent writes (ie: writes occur in >tag order, even if they are cached), then I think this satisifies soft >updates. You have no guarantee that the writes will be committed to the media in the order that they were reported as completed to the host if you use write caching. You do have a guarantee, however, that the cache contents are always consistent and if you allow the drive to flush it's cache, the media will eventually be consistent as well. >> >There were directory dependencies which were committed out of order >> >(the modified fsck reports these as soft dependency errors...). >> >> Can you be more specific? Are you positive that the transactions >> were committed out of order or could it be that some transactions >> were never committed at all? > >Transactions were committed out of order. If the transactions that >had been committed had been committed in order, then the loss of cached >transactions would only result in a rewind of state of the drive to >a previous state. The previous state, by definition, must also be >consistent. This is consistent with losing transactions. Certainly the writes could have been written out of order, but the failure should only occur if the drive loses transactions that were considered complete by the host. This should only happen by way of a power loss or power spike. >In other words, transaction dependency order as required for soft >updates must cause commits to the drives to occur in dependency >order, and the problem is the reordering of consecutive write >requests by the drive itself if there is *ever* a case where the >state is ever inconsistent. This is why you must have a UPS. I thought we already went over this before... >The only alternative is a dependency order bug, and such a bug >would be very easy to reproduce using a break-to-debugger or a >reset+fsck. Only if your break or reset+fsck hits at exactly the right time. You've used this argument yourself. -- Justin 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?199810140518.XAA15040>