Date: Sat, 05 May 2001 14:36:38 -0700 From: Nick Sayer <nsayer@quack.kfu.com> To: Nick Barnes <Nick.Barnes@pobox.com> Cc: freebsd-stable@freebsd.org Subject: Re: soft update should be default Message-ID: <3AF47266.4070805@quack.kfu.com> References: <5967.989094247@thrush.ravenbrook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Nick Barnes wrote: > This sounds as if there isn't _any_ way for the kernel (or, better, an > application) to make sure that its bits have got written. Is that > really true? Shouldn't the man pages for fsync(1), fsync(2), and > sync(8) reflect this? sync(2) has something under "BUGS".... Sure there is. 1. Disable write-caching on your drive. Currently this is the default anyway. There is a sysctl to control it. 2. Turn off soft-updates. 3. At that point, so far as I know, sync should work correctly. > > If this is true, it's not good. Presumably fsync(2) will get the data > down the cable to the disk unit. If the CPU, kernel, etc goes toes-up > a microsecond later, will my bits still hit the platter? They will if write caching in the disk is turned off AND the write operation actually completed (that is, the drive acknowledged completion). > I'm assuming > I can keep the power on, which is a separate and well-understood > problem. But if there's a panic and reboot, presumably there's some > kind of "reset now" message sent to the disk unit (the exact details > no doubt depend on the disk type). I believe the disk write caches are only in danger if power is unexpectedly lost. If you actually halt the OS, the disk will have time to finish the writes. > Will it write my bits or flush > them? How do different disk units compare in this respect? > > When I started with FreeBSD, the general understanding was that people > who cared about data integrity used SCSI, people who really cared used > RAID on SCSI, and people who were fanatical about it used hardware > SCSI-to-SCSI RAID in a separate rack unit with redundant PSUs and > controllers and very high-quality cables. Is this still the received > wisdom? I think with write-caching turned off and softupdates anyone should be happy unless they really require transactional recording (that is, if a transaction is acknowledged, then it must not ever be lost). Those folks should probably be running Oracle on a raw partition or some such. :-) With softupdates and no write-cache, I was able to start an untar of the ports tree (truly one of the worst-case scenarios -- lots of directories and tiny files), press RESET and come back up without much hassle. The net result of the fsck was that the filesystem was recovered to an exact moment in time slightly before when I actually hit RESET. That is, the metadata cache lagged behind realtime slightly, but was maintained perfectly. The cutoff between the preserved state and the lost state was perfectly temporal. That's why I would suggest those interested in transaction assurance not use softupdates. :-) 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?3AF47266.4070805>