Date: Mon, 28 Oct 2002 21:44:57 -0800 From: Peter Wemm <peter@wemm.org> To: "."@babolo.ru 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: <20021029054457.A905A2A88D@canning.wemm.org> In-Reply-To: <200210290542.g9T5g6PV036712@aaz.links.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
"."@babolo.ru wrote: > > "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. Maybe so, but FFS is written with the assumption that only the sector being written is at risk. Even losing 4-8 sectors blows that out the window if it happens to be metadata. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 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?20021029054457.A905A2A88D>