Date: Mon, 31 Jan 2000 02:08:45 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Gary Palmer <gjp@in-addr.com> Cc: Tom <tom@uniserve.com>, freebsd-stable@FreeBSD.ORG Subject: More than just logging, Re: JFS Message-ID: <20000131020845.T13027@fw.wintelcom.net> In-Reply-To: <82900.949299705@in-addr.com>; from gjp@in-addr.com on Mon, Jan 31, 2000 at 01:21:45AM -0500 References: <tom@uniserve.com> <82900.949299705@in-addr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Gary Palmer <gjp@in-addr.com> [000130 22:55] wrote: > Tom wrote in message ID > <Pine.BSF.4.05.10001302126530.23661-100000@shell.uniserve.ca>: > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000131020845.T13027>