From owner-freebsd-stable@FreeBSD.ORG Wed Sep 13 18:22:08 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF21716A412 for ; Wed, 13 Sep 2006 18:22:08 +0000 (UTC) (envelope-from bsd@kuehlbox.de) Received: from samael.qmail-ldap.de (mail.kuehlbox.de [62.159.47.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id A963F43D6A for ; Wed, 13 Sep 2006 18:22:04 +0000 (GMT) (envelope-from bsd@kuehlbox.de) Received: (qmail 8170 invoked from network); 13 Sep 2006 18:22:03 -0000 Received: from unknown (HELO [172.16.21.119]) (bsd@kuehlbox.de@[82.135.94.49]) (envelope-sender ) by samael.qmail-ldap.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 13 Sep 2006 18:22:03 -0000 Message-ID: <45084C3F.1030600@kuehlbox.de> Date: Wed, 13 Sep 2006 20:21:51 +0200 From: Teufel User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org References: <45066E19.2040405@kuehlbox.de> <20060913142329.GC70245@garage.freebsd.pl> <450823B1.2090809@kuehlbox.de> <20060913153909.GE70245@garage.freebsd.pl> In-Reply-To: <20060913153909.GE70245@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: gjournal and Softupdates X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2006 18:22:09 -0000 Pawel Jakub Dawidek wrote: >> [...] If so, this would be an advantage over SU, as >> it does surely not use the new introduced BIO_FLUSH. [...] >> > Soft-updates doesn't handle disk write caches at all. > you're totaly right. I was refering to the assumption of SU that the drive cache will not "lie" about its handling. >> [...] In the other hand i've seen couple of other JFS that went corrupt for "no reason". I don't want to be paranoid, but i >> really want to be "sure" that the design is trustable. >> > > Of course a bug in file system (or gjournal) implementation is still > possible and can lead to file system corruption, but such a bug can > still corrupt file system in the way it will not be fixable by fsck. > sooner or later bugs should be fixed. At least i will do some terrible test to gjournal in the next days. So in case expect some feedback. > From what I saw, file systems with journaling still enforce fsck every X > reboots or on the next reboot after Y days of uptime, whatever comes first. > That is also my experience. So hopefully gjournal will be an exception for this in the future :-) Thanks for clarifying and the great job. Stephan