Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!uunet!virtech!cpcahil
From: cpcahil@virtech.uucp (Conor P. Cahill)
Newsgroups: comp.unix.sysv386
Subject: Re: Why do you want a 512 byte block file system anyway?
Message-ID: <1990Nov21.134043.25732@virtech.uucp>
Date: 21 Nov 90 13:40:43 GMT
References: <1990Nov18.182135.17954@scuzzy.in-berlin.de> <1990Nov19.232124.7802@cichlid.com>
Reply-To: cpcahil@virtech.UUCP (Conor P. Cahill)
Distribution: comp
Organization: Virtual Technologies Inc., Sterling VA
Lines: 31

In article <1990Nov19.232124.7802@cichlid.com> aab@cichlid.com (Andy Burgess) writes:
>I just did an ls -l /usr/spool/news/comp/unix/sysv386 and I didn't see one
>file less then 512 bytes long. Most (estimate 90%) were over 1024 bytes
>long. Doesn't this mean 512 byte block buys you nothing?

No.  What matters is how many files fall between a 1K boundry and the next
512byte boundry.  If that number is high, then a 512 byte file system
may save you some space, but at the expense of performance.

If most of the files are between 0 and 512 bytes long then the 512 byte
file system will save you both space and performance.

If most of the files are between 513 and 1024 bytes long, then the 1K
file system wins both.

If most are between 1025 and 1536, then the 512 byte file system will 
save you some space, but will probably loose in the performance arena.

and this goes on ad nausium. 

NOTE that the space savings of a 512 byte file system decreases
linearly with the average size of the files while the performance hit
for using the smaller block increases linearly.  So don't use a 512 byte file
system unless your files all range between 0-512, or possibly 1025-1536 (
although I think the latter range will end up being a wash).


-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170