On Thu, Oct 30, 2008 at 10:05:43PM -0500, Rich Winkel wrote:
> On Thu, Oct 30, 2008 at 07:33:47PM -0700, Jeremy Chadwick wrote:
> > > One of the main functions of softupdates is to order disk updates in such
> > > a way that the fs organizational integrity is maintained at all times.
> > 
> > And we've recently found that this is simply not the case.  The benefits
> > of SU are applicable to very specific environments; desktop PCs are the
> > main ones, offering great performance improvements there.
> Thanks for pointing that out.  Is this an acknowledged bug in SU?  Is it
> still a problem in 7.0?

It's a problem in every release.  I believe it's more of an engineering
oversight; I don't know if it's truly fixable.  I guess there are some
kinds of filesystem errors which can't safely be fixed automatically.

There's no harm in background_fsck="no", but the reason that's not the
default is that most people want their system back up and working
immediately after a crash (don't want to wait for fsck to finish).

It's a personal choice: I would prefer the system stay down longer due
to a thorough fsck than have it come back up and still have some
underlying corruption that's being silenced.

The thread is below.  It is quite long and complex, so be sure to have
coffee or water on hand.


I kind of consider all of this "water under the bridge" now that ZFS is
available, and addresses all of these problems quite effectively.

> > > Of course this doesn't protect against actual sector corruption, but if
> > > the disk is between writes at the time it loses power, the fs structure
> > > is supposed to still be internally consistent.  At least that's my
> > > understanding of it.
> > 
> > Yep, that's how I understand it as well.  But this is a different topic
> > than what we were discussing 2-3 replies ago, talking about how a RAID
> > controller with cache + BBU is sufficient enough to guarantee data
> > integrity even when power is lost -- that's incorrect.
> The reason I brought it up is that it occurred to me that if the hardware
> raid card reorders disk i/o it would mess with SU's ordering.  I wonder
> whether this was happening in the previous thread you referred to
> concerning fsck?

Quite honestly, I don't understand the technical details of RAID card
I/O re-ordering vs. softupdates to be able to state "yeah, that's a
problem".  Someone much more familiar with the intricacies will have
to comment on this, and I believe freebsd-fs would be a better group
for that discussion, not -questions.

But I assume that if it was a problem, we'd be seeing a *very* large
number of business customers (making the assumption they're the ones
using hardware RAID cards) complaining regularly and loudly.

| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |

freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to