Date: Thu, 20 Sep 2001 20:29:16 -0700 From: "Kevin Oberman" <oberman@es.net> To: "Daniel O'Connor" <doconnor@gsoft.com.au> Cc: Nuno Teixeira <nuno.mailinglists@pt-quorum.com>, freebsd-stable@FreeBSD.ORG Subject: Re: hw.ata.wc && hw.ata.tags && softupdates short question Message-ID: <200109210329.f8L3TGR30860@ptavv.es.net> In-Reply-To: Your message of "Fri, 21 Sep 2001 12:18:32 %2B0930." <XFMail.20010921121832.doconnor@gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Fri, 21 Sep 2001 12:18:32 +0930 (CST) > From: "Daniel O'Connor" <doconnor@gsoft.com.au> > Sender: owner-freebsd-stable@FreeBSD.ORG > > > On 20-Sep-2001 Nuno Teixeira wrote: > > For what I heard, I concluded that we shouldn't use softupdates with write > > cache turned on. The first time that I tried this I loose a lot of work > > due to a power failure. > > You shouldn't use write caching, period. > > Well you can but if you lose power you WILL lose data. > > If you just want speed and care naught about your data go ahead :) > (I guess a UPS would increase your confidence) > > > 1. Can I use softupdates with hw.ata.wc="1" and hw.ata.tags="1" safely? > > > > 2. Does hw.ata.tags="1" "allows write caching to be safely turned on really? > > No, write caching tells the drive "Please lie to me about command completion" > so when the OS performs a write the drive caches it and says "yes that's on > disk", when it isn't. OK. I've seen some questionable information in this thread and some that I'm almost sure is simply wrong. I'm going to describe the situation as I understand it and if you are SURE something I say is wrong, please correct it. (Especially if you write disk drivers for FreeBSD. I have written disk drivers, but not in FreeBSD and not for ATA disks, so am not really competent.) 1. IBM drives that do tagging are claimed to be safe. The way tagging works should assure that the critical metadata is always written to disk. And tagging depends on write cache to work, but you don't need to turn it on as turning on tagging DOES turn on write cache as it is used by tagging and attempting to turn it on with the hw.ata.wc sysctl is meaningless and ignored. 2. On a disk that has a lot of writes like a news server is especially susceptible to data loss. If a system is not UPS protected and running software to shutdown cleanly before the UPS dies, write cache on a server is with ATA disks is probably a bad idea. But then again, ATA disks on a server are probably a bad idea. 3. The combination of soft updates and WC is especially risky as you might lose both the last bit of data written to disk, but metadata that can lead to a major corruption. Even then, it's reasonably unlikely, but I don't think reasonably unlikely is reasonable. 4. Some disks always write data (eventually). Some NEVER write out data that is re-written frequently. It's just about impossible to tell which a drive does and the only documentation is the drive's micro-code which you are very unlikely to ever see and less likely to understand unless you write disk code. (I have a friend who does and it is about as opaque a bunch of C++ as I have ever seen unless you REALLY understand disk design.) 5. Many disks seem to make NO attempt to write the data on power outage. I run with WC on my laptop because it's extremely unlikely to lose power. But I also back up the disk (dd mirroring) on a regular basis "just in case". It's also worth noting that Soren reversed himself and made wc default a few months after 4.3 was released. I assume it defaults to "on" in 4.4, although I have not checked. This makes me suspect that he decided that the risk was reasonable. But I really should not speak for him. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200109210329.f8L3TGR30860>