Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!pipex!uunet!Germany.EU.net!news From: bs@Germany.EU.net (Bernard Steiner) Newsgroups: comp.os.386bsd.questions Subject: buffer cach (was:Re: [BUG?] newfs with bsize = 16 kb ?) Date: 28 Oct 1993 09:33:38 +0100 Organization: EUnet Deutschland GmbH, Dortmund, Germany Lines: 16 Distribution: world Message-ID: <2ao052$43h@Germany.EU.net> References: <1993Oct23.193511.18122@Informatik.TU-Muenchen.DE> <2agbtr$5v0@Germany.EU.net> <NEWSSERV!STARK!GENE.93Oct25153858@stark.uucp> <CFI5oM.n3u@flatlin.ka.sub.org> <CGD.93Oct27232227@eden.CS.Berkeley.EDU> NNTP-Posting-Host: qwerty.germany.eu.net In article <CGD.93Oct27232227@eden.CS.Berkeley.EDU>, cgd@eden.CS.Berkeley.EDU (Chris G. Demetriou) writes: |> as previously noted, NetBSD has a complete and working buffer cache, |> and so we'll probably be bumping up MAXBSIZE to 16k in the next release. |> (to do so previously would have incurred a large performance penaltly, |> because *all* buffers under 0.9 are MAXBSIZE, which is obviously a |> memory hit if you've got all 8k file systems...) Q: In 386bsd 0.1/0.2.3 (yes, groan...) there's just some sort of LRU chain that gets used. IMVHO accessing cdrom filesystems is a real pain since not enough information is kept. Okay, so the problem may eventually go away with the isofs/cd(rom)fs/hsfs code being run as a user process, but until then, is there some sensible way of keeping track of "expensive" things and automagically keep them around for a longer time ? -Bernard