svn commit: r219667 - head/usr.sbin/bsdinstall/partedit

[Scott Long]

On Mar 20, 2011, at 10:34 PM, Jeff Roberson wrote:

> On Sun, 20 Mar 2011, Kirk McKusick wrote:
> 
>>> Date: Sun, 20 Mar 2011 13:25:20 -0700
>>> From: Doug Barton <dougb at FreeBSD.org>
>>> To: Marius Strobl <marius at alchemy.franken.de>
>>> CC: Kirk McKusick <mckusick at mckusick.com>,
>>>       Nathan Whitehorn <nwhitehorn at FreeBSD.org>, svn-src-head at FreeBSD.org,
>>>       Jeff Roberson <jeff at FreeBSD.org>, Gavin Atkinson <gavin at FreeBSD.org>,
>>>       svn-src-all at FreeBSD.org, src-committers at FreeBSD.org,
>>>       kvedulv at kvedulv.de
>>> Subject: Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit
>>> 
>>> On 03/20/2011 09:22, Marius Strobl wrote:
>>> 
>>>> I fear it's still a bit premature for enable SU+J by default. Rather
>>>> recently I was told about a SU+J filesystems lost after a panic
>>>> that happend after snapshotting it (report CC'ed, maybe he can
>>>> provide some more details) and I'm pretty sure I've seen the problem
>>>> described in PR 149022 also after the potential fix mentioned in its
>>>> feedback.
>>> 
>>> +1
>>> 
>>> I tried enabling SU+J on my /var (after backing up of course) and after
>>> a panic random files were missing entirely. Not the last updates to
>>> those files, the whole file, and many of them had not been written to in
>>> days/weeks/months.
>>> 
>>> With all due respect to the hard work that went into the code, I would
>>> be very uncomfortable with enabling it by default at this point.
>>> 
>>> 
>>> Doug
>> 
>> With all due respect, how can we fix things that nobody reports?
>> If you have a problem, let us know about it. And of course, we
>> need something more specific than the above.
> 
> I have not been following current but I read any emails sent directly to me without a mailing list in the cc.  I also was not aware of this.  I had not heard of any filesystem corruption problems at all.  If there are any, I also am not comfortable with enabling it by default.  I want to fix that first.
> 
> I have blocked off next week to work on this.  I already sent an email out to current@ requesting bug reports.  Please if you have anything else let me know immediately so I can prioritize it and start investigating.
> 

I haven't seen any data/metadata corruption issues with SUJ that weren't also present with SU (or just plain UFS).  The vast majority of problems that I've witnessed have happened on systems with ATA/SATA disks, hinting (IMHO) that it's really the long-standing problem of running these disks with their write caches enabled.  I don't think that I've encountered any appreciable problems on RAID controllers or SAS/SCSI disks with their write caches disabled.  Maybe with CAMATA maturing and supporting NCQ, we can turn off the SATA write caches as the default policy.

Scott