From owner-freebsd-current Thu Sep 26 12:42:30 2002 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 7FE6037B401 for ; Thu, 26 Sep 2002 12:42:28 -0700 (PDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 419C643E77 for ; Thu, 26 Sep 2002 12:42:24 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0400.cvx40-bradley.dialup.earthlink.net ([216.244.43.145] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17ueWO-0004Zg-00; Thu, 26 Sep 2002 12:42:00 -0700 Message-ID: <3D9362C1.CFA66F90@mindspring.com> Date: Thu, 26 Sep 2002 12:40:49 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alexander Leidinger Cc: freebsd-current@FreeBSD.ORG Subject: Re: Journaled filesystem in CURRENT References: <200209251319.g8PDJYoD047918@ib.com.ua> <20020925111232.B3686@Odin.AC.HMC.Edu> <20020926111949.5c0da160.Alexander@Leidinger.net> <20020926090325.A24614@zardoc.esmtp.org> <3D93459B.E4405568@mindspring.com> <20020926210947.5d5fdd45.Alexander@Leidinger.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Alexander Leidinger wrote: > On Thu, 26 Sep 2002 10:36:27 -0700 Terry Lambert > wrote: > > Journalling has advantages that a non-journalling FS with soft > > updates does not -- can not -- have, particularly since it is > > not possible to distinguish a power failure from a hardware > > failure from (some) software failures, and those cases need to > > Power failure: > No problem for both. > Hardware failure (I assume you think about a HDD failure): > Read failure: doesn't matter here > Write failure: either the sector gets remapped (no problem > for both), or the disk is in self destruct > mode (both can't cope with this) > Software failure: > Are you talking about bugs in the FS code? Or about a nasty > person which writes some bad data into the FS structures? > > > be treated differently for the purposes of recovery. The soft > > Sorry, I don't get it. Can you please be more verbose? This has been discussed to death before, and Kirk McKusick has already posted the definitive post on the topic to FreeBSD-FS. The upshot is that it is important to distinguish between an FS that had only bad cylinder group bitmap contents, and an FS that needs a more thorough consistency checking. You can not do this if the failure reason for the system is not recorded in non-volatile memory somewhere. For a power failure, this is practically impossible, unless you have AC loss notification with a sufficient DC holdup time (e.g. like in the InterJet II power supply). Note that recent disk drives (I *will not* call them "modern") will potentially trash sectors, if a power failure occurs during writes. One way to handle Scott Dodson's problem (for example) is to add a "softcheck started" flag in the superblock, so that if a crash occurs durin the abbreviated check, then the full check is done (this would fix Scott's disks, but would not fix the overall problem of a disk with errors that don't result in a panic, yet are not confined to the cylinder group bitmap contents). > > JFS that journals both data and metadata can recover from all > > three, to a consistant state, and one that journals only > > metadata can recover from two of them. > > SO writes the data directly to free sectors in the target filesystem. I > don't see where journaled data is an improvement in fs-consistency here. The write occurs, or it does not. The journal entry timestamp gets updated after the write completes, or it does not. Thus, you can always recover a JFS to a consistent state almost instantaneously, simply by finding the most recent valid journal entry timestamp, and ignoring anything else -- as long as data is journalled, and not just metadata. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message