Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.Hawaii.Edu!news.lava.net!coconut!www.nntp.primenet.com!nntp.primenet.com!cs.utexas.edu!iag.net!enews.sgi.com!EU.net!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!news-peer.gsl.net!news.gsl.net!howland.erols.net!newsxfer.itd.umich.edu!uunet!in3.uu.net!202.232.2.100!np1.iij.ad.jp!nf0.iij.ad.jp!nr0.iij.ad.jp!news.iij.ad.jp!news.CET.CO.JP!usenet From: "H. Asatani" <bjc@cet.co.jp> Newsgroups: comp.unix.bsd.freebsd.misc,comp.unix.bsd.bsdi.misc,comp.sys.sgi.misc Subject: Re: no such thing as a "general user community" Date: Thu, 20 Mar 1997 15:18:55 -0800 Organization: Budweiser Japan Company Lines: 44 Message-ID: <3331C5DF.7284@cet.co.jp> References: <331BB7DD.28EC@net5.net> <5gmb58$6jd$1@news.clinet.fi> <5gn3ig$83d@flea.best.net> <5goqrq$5ak$1@news.clinet.fi> <5gpcf9$767@flea.best.net> NNTP-Posting-Host: a04m.cet.co.jp Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.02 (Win16; I) Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:37433 comp.unix.bsd.bsdi.misc:6406 comp.sys.sgi.misc:29311 Matt Dillon wrote: > > XFs's claim to fame is: > > * hashed directory lookups, making namei() on large directories more > efficient (but only on large directories). Are you talking about an on disk structure. FBSD has a simple sequential on disk directory structure. There is a hashed name cache so assuming locality of reference... > * log file system .. fast startup after a crash verses the fsck you > have to do with ffs. So if your SGI box crashes a lot :-) ... just > kidding. Is this a log (journaling) system? FBSD has something called LFS but it is completely different. It's a log structured file system written by Margo Seltzer now at Harvard. In a log structured fs the files are the logs themselves. It optimises write performance over reads, heavily assuming LOR. They showed studies where the amount of actual reads were far less than the number of writes because the buffer cache worked so well. Unfortunately, LFS in FBSD probably won't be usable until maybe 3.0. > * 'real time' extensions in access and data layout. Useful for video > editing, not useful for anything else. > > * Ability to expand the size of an xfs filesystem partition via lfs > without having to dump/restore. A useful feature. > > The file creation/deletion/access rate is about the same. However, > BSD's namei() and general filesystem buffer cache implementation is a > whole lot better then SGI's, as are BSD's (4.4's) kernel locking > mechanisms. I think the primary benefit is the unified vm/buffer cache. The buffer cache is implemented as vm objects, see vfs_bio.c. On the other hand, I think FBSD's namei() needs work, based on looking at it and seeing some of the performance profiles posted to hackers. Regards, Mike Hancock