Date: Tue, 13 Oct 1998 22:05:06 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Terry Lambert <tlambert@primenet.com>, gibbs@plutotech.com (Justin T. Gibbs) Cc: 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: <199810140505.WAA17506@salsa.gv.tsc.tdk.com> In-Reply-To: Terry Lambert <tlambert@primenet.com> "Re: filesystem safety and SCSI disk write caching" (Oct 14, 12:49am)
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 14, 12:49am, Terry Lambert wrote: } Subject: Re: filesystem safety and SCSI disk write caching } > >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? I think we do. } 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. I believe the situation is that if you have write caching enabled, the drive will reorder the writes and it will tell you that the writes are done before they have been really gotten all the way to the platters. This might allow softupdates to issue more writes that might actually end up on the platters before the writes that they are dependent on. If the host CPU panics, this is still ok, because the combination of the pending writes in the drive cache and the data on the platters is in a safe state from the standpoint of what softupdates expects, and if the drive is not perturbed (by shutting off its power or doing something else that causes it to fail to commit the pending writes to stable storage), all the pending writes will complete and the bits on the platters will eventually end up in a "good enough" if not consistent state. } > What was the size of the directory. } } For me, it was a large directory; it was the full X11R6 source tree } from the XFree86 distribution (this is what Julian has used as one } of his tests at Whistle, so I did the same at home). I don't know in my case. } > Was the failure in directory creation or destruction? Which portion } > of the dependency graph was violated? } My *hunch* from what I was doing at the time (rm -rf) is "destruction", } but since I started this before all the creations were committed to } stable storage (only enqueued in the dependency queue), I can't } really say for sure what operation was in effect when I hit the reset } button. Maybe Don can elaborate on what he was doing when he hit } reset? I was doing the usual buildworld. I don't remember if it was in a creation or destruction phase when I hit reset. This was a couple weeks ago. 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?199810140505.WAA17506>