Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP id AA5225 ; Tue, 22 Dec 92 14:00:25 EST Xref: sserve comp.windows.x.i386unix:78 comp.unix.bsd:9190 Newsgroups: comp.windows.x.i386unix,comp.unix.bsd Path: sserve!manuel.anu.edu.au!munnari.oz.au!sgiblab!spool.mu.edu!umn.edu!csus.edu!netcom.com!hasty From: hasty@netcom.com (Amancio Hasty Jr) Subject: Re: [386BSD] Xfree86, XS3 Mouse configuration Message-ID: <1992Dec19.172946.10021@netcom.com> Organization: Netcom Online Communications Services (408-241-9760 login: guest) References: <BzGynG.E3J@NeoSoft.com> <1992Dec19.005008.5927@cbnewsj.cb.att.com> <1992Dec19.104955.16073@Informatik.TU-Muenchen.DE> Date: Sat, 19 Dec 1992 17:29:46 GMT Lines: 87 In article <1992Dec19.104955.16073@Informatik.TU-Muenchen.DE> roell@informatik.tu-muenchen.de (Thomas Roell) writes: >>> While I have the utmost respect for Roell's contributions, I am saddened >>> that he chose to flame Amancio like that. >> >>As are we all. > >I love to see this happen that Amancio turns everything I say into the >opposite and against me personally. And also note that I did said any word >about my contributions here, this is expilicitly about somebody elses >contributions, which I'm really missing named. > >What drives me really crazy, most of them time when he posts something, >he doesn't answer the question asked (see this recent ET4000 vs. ET4000/W32 >thread) instead he tells everybody how great his XS3 is. Besides this, read >carefully his reply to my posting. What I said was basically: > > - He talk on the net as if he was the only one doing XS3 alone > - The S3's graphics eingine differes only in one register from > a 8514/A > >What he answered was: > > - The README contains other names thomas forgot to mention that I cut and past my second statement on the README file stating clearly that XS3 was based on Kevin Martin's server. > - The S3's SVGA registers differ from that of a 8514/A (which is > natural since the 85: sserve!manuel.anu.edu.au!munnari.oz.au!hp9000.csc.cuhk.hk!saimiri.primate.wisc.edu!sdd.hp.com!cs.utexas.edu!uunet!spool.mu.edu!agate!agate.berkeley.edu!cgd From: cgd@eden.CS.Berkeley.EDU (Chris G. Demetriou) Newsgroups: comp.unix.bsd Subject: Re: Dumb Question: Why 512 byte block? Date: 19 Dec 92 00:07:39 Organization: Kernel Hackers 'r' Us Lines: 62 Message-ID: <CGD.92Dec19000739@eden.CS.Berkeley.EDU> References: <1992Dec18.005050.20594@decuac.dec.com> <1992Dec18.030833.7395@fcom.cc.utah.edu> <1gt736INNjje@menudo.uh.edu> <1992Dec18.235623.27538@fcom.cc.utah.edu> NNTP-Posting-Host: eden.cs.berkeley.edu In-reply-to: terry@cs.weber.edu's message of 18 Dec 92 23:56:23 GMT In article <1992Dec18.235623.27538@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: >>I did not think that Fast Unix File System works this way. >>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 >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? sorry. you guys *both* sound confused. first of all, i've never seen a FFS with 1k blocks; the most "standard" configuration is 4k or 8k blocks, with 8 fragments. this yields fragments of (obviously) 512bytes and 1k. you can't split *fragments* between one file. you *can* split blocks between one file, but this tends not to happen, because the FFS doesn't do this unless it's necessary. so: if you have 6 1.5k files, and the following filesystem setups, you get the following results: 8k blocks, 8frags/block: 6 blocks assigned, but major fragmentation... (actually, only 12 frags are used. if your filesystem is near full, < 6 blocks will be assigned). total space "actually used": 12k 8k blocks, 4frags/block: 6 blocks assigned, but major fragmentation... (actually, only 6 frags are used. if your filesystem is near full, < 6 blocks will be assigned). total space "actually used": 12k 4k blocks, 8frags/block: 6 blocks assigned, but major fragmentation... (actually, only 18 frags are used. if your filesystem is near full, < 6 blocks will be assigned). total space "actually used": 9k 4k blocks, 4frags/block: 6 blocks assigned, fragmentation "not too bad"... (actually, 12 frags are used. if your filesystem is near full, < 6 blocks