dangerous situation with shutdown process

[Paul Mather]

On Sat, 2005-07-16 at 16:16 +0200, Matthias Buelow wrote:
> David Taylor wrote:
> 
> >No.  I'm just asking if you know of ANY ata drives that will wait for the
> >cache to be flushed before claiming the disable cache command has
> >succeeded.  I don't, but I haven't looked.
> 
> I don't know either. I assume that they do. Does it matter?
> I mean, I'm not suggesting a frivolous new theory that is highly
> speculative and warrants a lengthy debate on its purported merits.
> What I described is common practice on Windows, Linux and probably
> a few other systems and I would think that they're not doing this
> for nothing. And, frankly, I'm a bit astonished that the FreeBSD
> (community) seems to be so ignorant of well-known measures for
> improving data safety on consumer-grade desktop hardware. Does that
> mean that FreeBSD is deemed generally unsuited for desktop and
> laptop use and should be reserved for servers with the appropriate
> (expensive) hardware? I hope not.

I recall reading on freebsd-current that Scott Long is working on adding
journalling support to FFS.  Perhaps you'd like to direct your input to
him instead of rehashing it repeatedly on here, which is the wrong
outlet for such discussion anyway: by definition, CURRENT, not STABLE
will get a new feature like journalling, and so discussing the ins and
outs of it on freebsd-current would seem more apropos.  (Plus, I'd hate
to see him implement something only for you to declare it to be "the
wrong way to do things."  Better to get your 2p in now.:)

Reagrding your question of "does that mean that FreeBSD is deemed
generally unsuited for desktop and laptop use," I can speak only from
experience.  I run 6-CURRENT on an ATA system using softupdates on my
desktop, and have been doing so for quite some time.  I've seen through
quite a few periods of extreme growing pains for CURRENT, with seemingly
random panics and mystery crashes at times.  (Who can forget the dark
days of the ULE + PREEMPTION instability?)  Add to the mix that my
neighbourhood has pretty flaky power, with a tendency for short
interruptions at the first whiff of bad weather.  This all adds up to a
good smattering of reboots at inopportune times (like when doing
buildworlds or large portupgrade sessions:).

Despite that, I have never EVER had a problem with data consistency on
my file systems.  (The only problem I have had is when I added an ATA
controller card one time and forgot to disable its RAID BIOS, which
promptly spammed over my geom_mirror metadata.:)  If softupdates were as
unsafe as you often hint, I'm surprised that I haven't lost a file
system by now.  (I would also expect to hear from the field a lot more
clamour about how unsafe it is, and that, in fact, the sky was indeed
falling.)  I guess I must be amazingly lucky and should start playing
the lottery right now. :-)

The main inconvenience I have with panics or outages is the fsck times
on reboot.  (Actually, what I find to be more inconvenient is the
resynchronisation time needed for my geom_mirror, which takes a lot
longer than a fsck.)  I understand that fsck delays for large file
systems is the major impetus behind the journalling work, not as a fix
for a perceived data consistency problem.

Cheers,

Paul.

PS: I also use softupdates on my NetBSD systems, again without problems.
I've also used LFS on NetBSD at times, but have always ended up
abandoning it due to performance and severe data reliability problems.
(To be clear, though, I'm not sure LFS was deemed to be for "production
use," at least not the times I tried it.)
-- 
e-mail: paul at gromit.dlib.vt.edu

"Without music to decorate it, time is just a bunch of boring production
 deadlines or dates by which bills must be paid."
        --- Frank Vincent Zappa