Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 22 Jun 1996 12:03:01 -0700 (PDT)
From:      Gary Kline <kline@tera.com>
To:        jmb@freefall.freebsd.org (Jonathan M. Bresler)
Cc:        anneb@svl.tec.army.mil, kline@tera.com, black@mr.net, questions@freebsd.org
Subject:   Re: LFS anyone?
Message-ID:  <199606221903.MAA16245@athena.tera.com>
In-Reply-To: <199606212004.NAA22850@freefall.freebsd.org> from "Jonathan M. Bresler" at "Jun 21, 96 01:04:42 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
According to Jonathan M. Bresler:
> Anne Brink wrote:
> > 
> > > According to Ben Black:
> > > 	Seems like the LFS would make fsck's obsolete.  Yes? No?
> > 
> > 
> > Yes, LFS does some rollbacks after a crash, BUT, the file system is not
> > checked. It's just assumed to be fine. Fsck actually does verify that you
> 
> 	LFS works forward from a 'checkpoint' to reconstruct the filesystem
> 	in the event of a crash.  at the time the checkpoint was written
> 	the filesystem was stable and consistent.  there are two checkpoint
> 	regions on disk, the active checkpoint toggles back and forth between
> 	the two.  the last item written to disk is the toggle.
> 
> > like syslogs and mail logs and things like that.  If you have lots of random
> > file accesses, especially over NFS which caches things in blocks, not whole
> > files, you may lose a /lot/ of the LFS functionality, and possibly get worse
> > performance than with FFS.  The LFS model isn't consistent with the concept
> > of cylinder groups, but uses the theory of locality which helps its efficiency.
> > As for a regular user file system? Well, I'd want to run some benchmarks. (-;
> 
> 	memory, memory, memory.  for LFS to be effective on general purpose
> 	uses, you must have enough memory to satisfy a very large percentage
> 	of reads from the (now unified vm and ) file cache.
> 
> 	at least this is my understanding of LFS, i may be wrong
> 	i imagine that i will find out ;)
> 

		Interesting stuff.  For my own system, or for 
		any system, data integrity is the critical issue.
		Memory is cheap (or at least reasonable); getting
		more so.

		gary

		(dreaming of those 4GB SIMM's :-)

> 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606221903.MAA16245>