Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.bbnplanet.com!howland.erols.net!newsfeed.internetmci.com!news.dti.ad.jp!news-jp-0.abone.net!np1.iij.ad.jp!nf0.iij.ad.jp!nr0.iij.ad.jp!news.iij.ad.jp!news.CET.CO.JP!usenet From: Michael Hancock <michaelh@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: Sun, 30 Mar 1997 12:44:49 +0900 Organization: CET Lines: 60 Message-ID: <333DE1B1.49C6@cet.co.jp> References: <331BB7DD.28EC@net5.net> <5goqrq$5ak$1@news.clinet.fi> <5hd29s$e7t@fido.asd.sgi.com> <5he3pp$8ms$2@kayrad.ziplink.net> <5hfh2l$i13@flea.best.net> <5hfl3n$a3t@fido.asd.sgi.com> <333C0CD6.6BD6@cet.co.jp> <5hid66$k6c@fido.asd.sgi.com> NNTP-Posting-Host: a07m.cet.co.jp Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (Win95; I) Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:38121 comp.unix.bsd.bsdi.misc:6521 comp.sys.sgi.misc:29548 Larry McVoy wrote: > > Michael Hancock (michaelh@cet.co.jp) wrote: > : Margo's LFS system is a log structured fs. The logs ARE the files. Are you > : saying this is how XFS works? > > Absolutely not. Anyone with an ounce of filesystem sense can figure > out that the allocation is a huge part of the logic that goes into a > file system. It is critically important that you put the data where it > belongs. That, in a nutshell, is what is wrong with LFS. Putting the > data where the head happens to be is just plain stupid. Harsh words. > I wouldn't use them if it were the efforts of an undergrad. But a PhD > in operating systems should know better. There are many excellent papers > which describe in great detail why allocation policy is important. The > LFS folks, by telling the world that LFS is a good idea, have done all of > us a disservice. Those of us who have to ship product now have to explain > to managers why LFS isn't a good idea. I think it would be interesting to see how well BSD LFS works out anyway. After all XFS is 100,000 lines of code and very complex, it would be much easier to get LFS to work with FBSD's VM framework than to do the meta-data journaling, hashed directory, and extent based thing from scratch. Going thru years of delivering buggy code just doesn't sound like a lot of fun. I understand that really takes a while to get it right, so this isn't a knock on SGI. I read that LFS favors write over read performance heavily depending on locality of reference to make up for the read performance. FBSD has a unified VM and buffer cache and does other things like favoring reads of pushed out pages from swap instead of the vnode so it can help make up for read hit even more. I think it's practical for us to look at LFS for a developer's PC where there would be a lot of tarring, compiling, and linking activity. Cleanerd could be scheduled to run at night to deal with the circular log so it wouldn't be a performance factor for this application. Doesn't this make sense? I'll dig up the papers you cite, I get the feeling that some of the assumptions are out of date. I do agree that LFS isn't going to make a good general purpose fs mainly because of the unpredictability of cleanerd, but for some special purpose environments I think it'll be fine. Regards, Mike Hancock > That is NOT the sort of help I want from the research community. They > should be embarressed and ashamed of themselves for this junk. We all > make mistakes. We don't all try and market our mistakes as good ideas. > There is a certain lack of integrity that just burns me up. > > XFS, like any other log based file system, uses the log exactly like a > database uses the log. The data goes where it should, the transactions > are logged in the log. See Ray Chen's post on the topic or read the > Usenix paper for more info. > -- > --- > Larry McVoy lm@sgi.com http://reality.sgi.com/lm (415) 933-1804