From owner-freebsd-stable Tue Apr 4 13:57:59 2000 Delivered-To: freebsd-stable@freebsd.org Received: from home.offwhite.net (home.offwhite.net [156.46.35.30]) by hub.freebsd.org (Postfix) with ESMTP id 1C8CE37BF08 for ; Tue, 4 Apr 2000 13:57:54 -0700 (PDT) (envelope-from brennan@offwhite.net) Received: from localhost (brennan@localhost) by home.offwhite.net (8.9.1/8.9.3) with ESMTP id PAA43400; Tue, 4 Apr 2000 15:57:50 -0500 (CDT) Date: Tue, 4 Apr 2000 15:57:50 -0500 (CDT) From: Brennan W Stehling To: "Chad R. Larson" Cc: freebsd-stable@FreeBSD.ORG Subject: Re: journaling fs In-Reply-To: <200004042048.NAA09569@freeway.dcfinc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This sounds to be very promising. When I was running a server a while back I always go the impression that the server was already running some service to clean up the system. I do know know the filesystem (ufs) well enough to know if it that is true or not. It always seemed to me that file fragmentation was updated routinely and the disk run efficiently. I think ufs is very solid right now... just sucks when something goes wrong, but that is more a limitation of my own experience and not the software. I am sure I could fix just about anything on the filesystem if I had a better understandinf of newfs and fsck, but because it is so solid I use them so rarely. That is good and bad... Brennan Stehling - web developer and sys admin projects: www.greasydaemon.com | www.onmilwaukee.com | www.sncalumni.com fortune: Only presidents, editors, and people with tapeworms have the right to use the editorial "we." On Tue, 4 Apr 2000, Chad R. Larson wrote: > As I recall, Brennan W Stehling wrote: > > Are there any efforts to build a journaling filesystem for FreeBSD? I > > have read of several for Linux, but none for FreeBSD. > > There are a couple of projects underway, though I think they are > either being done in concert with the Linux guys or are planned > ports of the Linux stuff when it's completed. Plus SGI's promise to > OpenSource its journaling file system should offer yet another path > when it happens. > > > fsck is just so slow, especially when my drives tend to get so much > > larger than before. I have a new 30 gigger and running and fsck on > > that will take a long time. If it ever falls hard it will take > > forever to reboot. > > One of the designers of UFS back at Berkeley has been working on > enhancements that should eliminate the very long fsck runs. Perhaps > you've seen reference to "softupdates". That's the first part of > the project, in which all the filesystem metadata (the data > concerning the data, like inodes) has been being analysed as to how > much needs to be actually kept current on the disk. Those portions > that can be recreated from other things known about the disk are no > longer forced to "sync" on the disk. This has made major throughput > improvements in the UFS, especially in environments where the > contents of the filesystem churn (like, /tmp). > > The next part of the project is an "fsck daemon" that can run in the > background and repair filesystem structure inconsistancies. Then, > if you have an unplanned stoppage, the disk will be usable > immediately after a reboot. It just might have some unused space > that is not visable at first. > > -crl > -- > Chad R. Larson (CRL15) 602-953-1392 Brother, can you paradigm? > chad@dcfinc.com chad@larsons.org larson1@home.net > DCF, Inc. - 14623 North 49th Place, Scottsdale, Arizona 85254-2207 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message