From owner-svn-src-all@FreeBSD.ORG Mon Mar 21 05:45:12 2011 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDF23106566C; Mon, 21 Mar 2011 05:45:11 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 8D3288FC18; Mon, 21 Mar 2011 05:45:11 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id p2L5j4RD005325; Sun, 20 Mar 2011 23:45:04 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: Date: Sun, 20 Mar 2011 23:45:04 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <25AA5841-B700-463A-BD52-9FD18650E859@samsco.org> References: <201103210342.p2L3gWM9057768@chez.mckusick.com> To: Jeff Roberson X-Mailer: Apple Mail (2.1082) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org X-Mailman-Approved-At: Mon, 21 Mar 2011 11:16:42 +0000 Cc: Doug Barton , kvedulv@kvedulv.de, Jeff Roberson , Kirk McKusick , Gavin Atkinson , Nathan Whitehorn , src-committers@FreeBSD.org, Marius Strobl , svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org Subject: Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 05:45:12 -0000 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 >>> To: Marius Strobl >>> CC: Kirk McKusick , >>> Nathan Whitehorn , = svn-src-head@FreeBSD.org, >>> Jeff Roberson , Gavin Atkinson = , >>> 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