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>
index | next in thread | previous in thread | raw e-mail
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@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 >>> >>> 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. Scotthelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25AA5841-B700-463A-BD52-9FD18650E859>