Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 4 Apr 2000 15:57:50 -0500 (CDT)
From:      Brennan W Stehling <brennan@offwhite.net>
To:        "Chad R. Larson" <chad@DCFinc.com>
Cc:        freebsd-stable@FreeBSD.ORG
Subject:   Re: journaling fs
Message-ID:  <Pine.BSF.4.10.10004041554000.42136-100000@home.offwhite.net>
In-Reply-To: <200004042048.NAA09569@freeway.dcfinc.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.10004041554000.42136-100000>