From owner-freebsd-current@FreeBSD.ORG Sun May 11 21:10:59 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 220E337B401 for ; Sun, 11 May 2003 21:10:59 -0700 (PDT) Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by mx1.FreeBSD.org (Postfix) with SMTP id 9A41243FE0 for ; Sun, 11 May 2003 21:10:58 -0700 (PDT) (envelope-from q_dolan@yahoo.com.au) Received: from vdub.onthenet.net (HELO ?172.22.1.10?) (q?dolan@203.10.89.16 with plain) by smtp.mail.vip.sc5.yahoo.com with SMTP; 12 May 2003 04:10:58 -0000 From: Q To: current@freebsd.org In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Organization: Message-Id: <1052712730.2211.96.camel@boxster.home.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 12 May 2003 14:12:11 +1000 Content-Transfer-Encoding: 8bit Subject: RE: Regression observations & misc errata X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2003 04:10:59 -0000 Thanks for that, I will look into it. However, you might have missed my point. The couple of times I have had fatal filesystem inconsistencies have been after a kernel panic, or ACPI induced ungraceful powerdown, and even then it is so rare I cannot deliberately reproduce the problem. Regardless of this, my point was not that the inconsistency occured, but rather there has been a change in the resultant system behaviour compared to pre 5.x releases. In the past the system would have failed the fsck and dropped back into single user mode allowing for manual intervention, now the system will boot normally and kernel panic the moment the filesystem error is encountered. The resolution is simple enough, but the cause of the panic may not be immediately obvious, or may take several minutes to occur. Seeya...Q On Mon, 2003-05-12 at 13:34, 李鑫 Xin LI wrote: > > -----Original Message----- > > From: owner-freebsd-current@freebsd.org > > [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Q > > Sent: Monday, May 12, 2003 9:57 AM > > To: current@freebsd.org > > Subject: Regression observations & misc errata > > > > o Particularly bad "crashes" can leave the filesystem in such a state > > that continuing without a foreground fsck will cause a kernel panic > > when the effected files are accessed. > > I had a /var that exhibited this problem, only solution to panic was > > single user mode boot and 'fsck -y' (no tracelog sorry) > > I believe that this is some misunderstood. Foreground fsck is necessary when > there is unexpected Soft Updates inconsistency, which can only arise on two > situations: > o Hardware error, for example, disk hard read/write error > o Misconfiguration. This is common in 5-CURRENT and 4-STABLE boxes with ATA > hard disk installed on the system. > > What I will mainly willing to explain is the misconfiguration. By default, > ATA write caching is enabled without ATA tagged queuing enabled. ATA tagged > queuing is not enabled by default because only limited recent models of hard > disk support this feature, and the ATA write cache, when not combined with > tagged queuing, put the file system in a considerable danger of data loss, > besides the significant performance improve. > > Why ATA write cache will damage consistency? Because when having this > feature enabled, the driver tend to report 'write is completed' right after > it obtained data to be written and put it to the on board cache. > Unfortunately, this behavior is not a good manner to the soft updates which > requires driver to tell it the true situation whether the data is on > reliable storage. On most SCSI hard disk drivers, however, because the > tagged queuing capability, the soft updates code get the real situation > about data, and there would be no problem with 'bad crashes'. Recently, IBM > and some other manufactures have introduced tagged queuing into ATA devices, > this would be a good news, and you might be glad if your hard driver is > listed in ata(4) manpage indicating it has the feature, which is tunable in > device.hints(5). > > For one of my own testing FreeBSD boxes, which is a 5 years old Pentium-II > with IDE hard drive which definitely doesn't support tagged queuing, I have > disabled hw.ata.wc as soon as I have installed FreeBSD 5-CURRENT snapshot on > it. This dramatically decreases the performance, but I got no problem in any > crashes, except the ffs_blkfree panic caused by a small bug in recent vm > change during update. > > So I think you will find a way that, either accept the fact that with wc > enabled, soft updates may panic across system crashes, or to accept the > performance decrease. And if you have newer models of IBM hard disk, you > will be lucky for you have the third choose. > > Hope the information above helpful, and I will thank you in advance. > > Cheers, > delphij