svn commit: r219667 - head/usr.sbin/bsdinstall/partedit
scottl at samsco.org
Mon Mar 21 05:45:12 UTC 2011
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
>>> 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
>>> 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.
>> 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.
More information about the svn-src-head