From owner-freebsd-stable Mon Jan 31 1:43:32 2000 Delivered-To: freebsd-stable@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 8F0DF14C4B for ; Mon, 31 Jan 2000 01:43:29 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) id CAA28362; Mon, 31 Jan 2000 02:08:46 -0800 (PST) Date: Mon, 31 Jan 2000 02:08:45 -0800 From: Alfred Perlstein To: Gary Palmer Cc: Tom , freebsd-stable@FreeBSD.ORG Subject: More than just logging, Re: JFS Message-ID: <20000131020845.T13027@fw.wintelcom.net> References: <82900.949299705@in-addr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <82900.949299705@in-addr.com>; from gjp@in-addr.com on Mon, Jan 31, 2000 at 01:21:45AM -0500 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Gary Palmer [000130 22:55] wrote: > Tom wrote in message ID > : > > On Sun, 30 Jan 2000, Daniel C. Sobral wrote: > > > > > > Due to the lack of interest, FreeBSD's LFS has fallen into disrepair > > > > over the years. With the implementation of softupdates in FreeBSD I > > > > don't think there is any need for LFS any more. > > > > > > Repeat that over and over the next time you wait fsck finish a 40 Gb > > > filesystem checkup, and see if you manage to convince yourself of that. > > > > Actually, one of the goals of the softupdates development is a fsck'less > > filesystem. I'm not sure how this is to be achieved. Probably a metadata > > journal, though that is just speculation. All the work on metadata update > > ordering in softupdates would probably apply very nicely to a journal. > > The way I understand it is that SoftUpdates is meant to leave the > metadata consistant enough that the filesystem can be mounted > read/write immediately at boot, and then have a background fsck go > through and remove blocks which are allocated in the bitmaps, but > aren't really used. The only thing you lose by not running the > background daemon is space. I don't think anyone's running like this > today, but that is Kirks plan. (This is me (hopefully accurately) repeating something that Terry Lambert brought to my attention, credit where credit is due. The safe-shutdown is my rambling on about a solution.) Why logging filesystems don't work: You generally (with the hardware available in PCs now) can't tell the difference between: 1) loss of power (ok!) 2) crash where the filesystem datastructures weren't corrupted (ok!) 3) crash where the filesystem datastructures were corrupted (ouch) 4) crash where the disk/bus got scrambled (ouch) the problems with 3 and 4 really make a logging filesystem a "shot in the dark" because you never know if "safe" areas on the disk really are safe because there was a chance for corruption. How do you know that a bug in some other code didn't trounce on the filesystem's data and write to a spot that's supposedly "committed"? Since you generally can't tell between 1,2,3 and 4 you really ought to fsck in the background anyway. Good news: afaik Kirk is working on this capability! Bad news: people running depending on _only_ logging are kidding themselves. Mini-fix for this problem: Providing safe shutdown points for the filesystem, if something "weird" is found, disable further access to that file/directory or possibly shutdown the entire filesystem. Basically instead of panic'ing when invalid structures are read from disk, just disallow further access to the objects. patches anyone? :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message