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 <do...@freebsd.org> >>> To: Marius Strobl <mar...@alchemy.franken.de> >>> CC: Kirk McKusick <mckus...@mckusick.com>, >>> Nathan Whitehorn <nwhiteh...@freebsd.org>, svn-src-h...@freebsd.org, >>> Jeff Roberson <j...@freebsd.org>, Gavin Atkinson <ga...@freebsd.org>, >>> svn-src-all@FreeBSD.org, src-committ...@freebsd.org, >>> kved...@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 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
