Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP id AA5218 ; Tue, 22 Dec 92 13:00:19 EST Newsgroups: comp.unix.bsd Path: sserve!manuel.anu.edu.au!munnari.oz.au!sgiblab!darwin.sura.net!bogus.sura.net!pandora.pix.com!stripes From: stripes@pix.com (Josh Osborne) Subject: Re: Dumb Question: Why 512 byte block? Message-ID: <BzIEv1.G7G@pix.com> Sender: news@pix.com (The News Subsystem) Nntp-Posting-Host: pandora.pix.com Organization: Pix Technologies -- The company with no adult supervision References: <1992Dec18.030833.7395@fcom.cc.utah.edu> <1gt736INNjje@menudo.uh.edu> <1992Dec18.235623.27538@fcom.cc.utah.edu> Date: Sat, 19 Dec 1992 13:59:23 GMT Lines: 62 In article <1992Dec18.235623.27538@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: [...] >>If you have 6 1.5K files using 1K blocks, >> 6 1k blocks will take each 1K from each file, and >> 3 1k blocks will take 0.5k from each file. >>This was my understading from the famous FUFS paper. > >You can't split blocks between files. A block is, by definition, the >smallest possible allocation unit. Thin about the case where you have Under the FFS the fragment is the smallest allocation unit, and fragments are only allocated at the end of a file. The rest of the file is in blocks. >a 1 byte file and a 1 block - 1 byte file; what would you do when >adding one or two characters to the first (1 Byte)? TReallocate? Shift >and reallocate for the last byte of the second file? When you extend a file that ends in a fragment it is relocated. That is one reason to go through stdio (which with normal block and fragment sizes only writes one or more whole blocks except on a ffluch(), or fclose()). >But... you're right that it doesn't work the way I've shown... thought >for sure I'd get bombarded on this one: >>>Obviously, if I have 6 1.6K files, both blocking factors take up 512K. >should have read: >>>Obviously, if I have 6 1.6K files, both blocking factors take up 12K. > >1.6K rounded to a both a 512b and 1K bo09:01:16 EST Newsgroups: comp.unix.bsd Path: sserve!manuel.anu.edu.au!munnari.oz.au!hp9000.csc.cuhk.hk!saimiri.primate.wisc.edu!sdd.hp.com!ux1.cso.uiuc.edu!news.cso.uiuc.edu!uxa.cso.uiuc.edu!jwp20406 From: jwp20406@uxa.cso.uiuc.edu (Jeffrey Palmer) Subject: An interesting problem (and solution?) Message-ID: <BzHwLG.Dn0@news.cso.uiuc.edu> Sender: usenet@news.cso.uiuc.edu (Net Noise owner) Organization: University of Illinois at Urbana Date: Sat, 19 Dec 1992 07:24:50 GMT Lines: 46 Hey all, I love 386bsd, but lately I have been having some very strange problems... I was just windering if anyone else out there might have an idea as to why in the world my system would be doing this... The problem first started when I attempted to install a second Western Digital 2200a 200 Meg drive in my 486-50 Gateway 2000 (which I've had no problems with, in relation to 386bsd). I found out quickly that I needed patches, so patch away I did... I tried the barsoom patches, but they didn't work. It seemed that they would see only the initial drive on my controller, and instead of a second drive, all I saw was another image of the first. Well, needless to say, that didn't do me any good. I installed the other 2nd hard-drive patches from the unofficial directory at agate, and they worked like a charm. However, although I could now label and newfs my drive, whenever I tried to mount or access the drive at startup, the label seemed to have a habit of either disappearing or causing the mmachine to hang while loading. Well, since I just finished finals I decided to dig around in 'ufs_disksubr.c' I wanted to find out where exactly my machine was crashing. Now I know this sounds like a bogus way to go about this, but I don't know too much about kernel debugging, so I put in some printf