Date: Sun, 20 Mar 2011 23:45:04 -0600 From: Scott Long <scottl@samsco.org> To: Jeff Roberson <jroberson@jroberson.net> Cc: Doug Barton <dougb@FreeBSD.org>, kvedulv@kvedulv.de, Jeff Roberson <jeff@FreeBSD.org>, Kirk McKusick <mckusick@mckusick.com>, Gavin Atkinson <gavin@FreeBSD.org>, Nathan Whitehorn <nwhitehorn@FreeBSD.org>, src-committers@FreeBSD.org, Marius Strobl <marius@alchemy.franken.de>, svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org Subject: Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit Message-ID: <25AA5841-B700-463A-BD52-9FD18650E859@samsco.org> In-Reply-To: <alpine.BSF.2.00.1103201831270.1480@desktop> References: <201103210342.p2L3gWM9057768@chez.mckusick.com> <alpine.BSF.2.00.1103201831270.1480@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 20, 2011, at 10:34 PM, Jeff Roberson wrote: > On Sun, 20 Mar 2011, Kirk McKusick wrote: >=20 >>> Date: Sun, 20 Mar 2011 13:25:20 -0700 >>> From: Doug Barton <dougb@FreeBSD.org> >>> To: Marius Strobl <marius@alchemy.franken.de> >>> CC: Kirk McKusick <mckusick@mckusick.com>, >>> Nathan Whitehorn <nwhitehorn@FreeBSD.org>, = svn-src-head@FreeBSD.org, >>> Jeff Roberson <jeff@FreeBSD.org>, Gavin Atkinson = <gavin@FreeBSD.org>, >>> svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, >>> kvedulv@kvedulv.de >>> Subject: Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit >>>=20 >>> On 03/20/2011 09:22, Marius Strobl wrote: >>>=20 >>>> 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. >>>=20 >>> +1 >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>>=20 >>> Doug >>=20 >> 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. >=20 > 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. >=20 > 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. >=20 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25AA5841-B700-463A-BD52-9FD18650E859>