Date: Fri, 21 Jun 1996 13:04:42 -0700 (PDT) From: "Jonathan M. Bresler" <jmb> To: anneb@svl.tec.army.mil (Anne Brink) Cc: kline@tera.com, black@mr.net, questions@freebsd.org Subject: Re: LFS anyone? Message-ID: <199606212004.NAA22850@freefall.freebsd.org> In-Reply-To: <199606211936.PAA11013@svl.tec.army.mil> from "Anne Brink" at Jun 21, 96 03:36:05 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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 ;) jmb -- Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG FreeBSD--4.4BSD Unix for PC clones, source included. http://www.freebsd.org/ PGP 2.6.2 Fingerprint: 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606212004.NAA22850>