Date: Tue, 29 Oct 2002 08:42:05 +0300 (MSK) From: "."@babolo.ru To: Peter Wemm <peter@wemm.org> Cc: "Daniel O'Connor" <doconnor@gsoft.com.au>, Chuck Robey <chuckr@chuckr.org>, Kenneth Culver <culverk@yumyumyum.org>, "Wilkinson, Alex" <Alex.Wilkinson@dsto.defence.gov.au>, hackers@FreeBSD.ORG Subject: Re: [hardware] Tagged Command Queuing or Larger Cache ? Message-ID: <200210290542.g9T5g6PV036712@aaz.links.ru> In-Reply-To: <20021029042415.967662A88D@canning.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> "Daniel O'Connor" wrote: > As you can imagine, this violates the basic assumptions of FFS and softdep. > They assume that only sectors that are written to are at risk, and do all > their ordering based on that assumption. But the assumption is completely > bogus. Even with no-caching it doesn't work because if the drive loses > power after only having written half of the track, then you risk losing the > rest - the track is written from "wherever", and not any index marks. ie: > the track is just as likely to overwrite the second half of the sectors > first, and when you lose power, you have two copies of the first half of > the sectors. Basically you have to assume that the entire track and > all of the nearby sectors could get lost or trashed. I usually lose 4..8 sectors cluster on fast power down on IBM IDE drives. Repairable. -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210290542.g9T5g6PV036712>