dangerous situation with shutdown process
jd at ugcs.caltech.edu
Thu Jul 14 20:14:10 GMT 2005
softupdates is perfectly safe with SCSI.
its well known that ide and sata w/wo ncq fails to provide suitable
semantics for softupdates
however, journaling fairs no better, and request barriers do nothing to
solve the problem.
Request Barriers under linux exist to prevent the low level kernel block
device layer from reordering write operations from the upper file system
layers. Request Barriers consist of nothing more than tagging internal
queues within the Linux kernel itself. They do nothing to resolve the
underlying failures of the hardware to provide proper semantics to the
block device layer.
but, Request Barriers are ultimately useless. They can't resolve the
underlying problems with ide/sata and there are already exposed semantics
if you absolutely must use sata and have reliable writes, make use of sata
with battery-backed raid controller.
On Thu, 14 Jul 2005, Matthias Buelow wrote:
> Kevin Oberman wrote:
> >> How can I fix it on my system?
> >SCSI or ATA? If it's ATA, turn off write cache with (atacontrol(8) or
> >the sysctl.
> You do NOT want to do that. Not only will performance drop brutally
> (example: drop to 1/5th of normal write speed for sequential writes,
> probably worse for random writes) but it will also significantly
> reduce the lifetime of your disk. Modern disks are designed to be
> used with the write-back cache enabled, so don't turn it off.
> >The problem is that disks lie about whether they have actually written
> >data. If the power goes off before the data is in cache, it's lost.
> No, the problem is that FreeBSD doesn't implement request barriers
> and that softupdates is flawed by design and seemingly could not
> make use of them, even if they were available (because, as I
> understand it, it relies on a total ordering of all writes, unlike
> the partial ordering necessary for a journalled fs).
> Until a journalled fs that uses write request barriers is available
> for FreeBSD, you better had a reliable UPS.
> freebsd-stable at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
More information about the freebsd-stable