NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/unix/bsd/10429

Text File | 1992-12-21 | 3.6 KB | 75 lines

Newsgroups: comp.unix.bsd
Path: sparky!uunet!haven.umd.edu!darwin.sura.net!bogus.sura.net!pandora.pix.com!stripes
From: [e-mail] (Josh Osborne)
Subject: Re: Dumb Question: Why 512 byte block?
Message-ID: <[e-mail]>
Sender: [e-mail] (The News Subsystem)
Nntp-Posting-Host: pandora.pix.com
Organization: Pix Technologies -- The company with no adult supervision
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 19 Dec 1992 13:59:23 GMT
Lines: 62

In article <[e-mail]> [e-mail] (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 boundry is 2K, and 2k * 6 = 12k.
[...]
>Consider the most ridiculous possible situation:  I have a 1G disk with
>a 1G blocking factor (impossible without rewriting the buffering code).
>
>How many files can I have on the disk? (Ignore the blocks allocated to inodes
>and directoryies 8-P).

With the frags per block set at 8 (I beleve the normal, and highest setting),
you could have 8 files, but only if you were root (the avail-free space for
non-root users may be done only in blocks, and count a block with 1 frag
"used").

I think the BSD FFS is normally configured with 8K blocks, and 1K fragments,
or 4K blocks and 512b fragments.  So the figures for 1.6K files you gave
are correct for the 4K/512b system, and low for the 8K/1K system.  However
I don't think anything prevents you from having a 1K/128b filesystem (except
the block device drivers for disks, and mabie the buffer cache).

I would like to see the number of frags/block uped to 32 so we can have
32K/1K, or 16K/512b filesystems, which after stdio is changed to use bigger
buffers should improve disk read/write speed without effecting the amount
of disk we can make use of.

(info from The Design and Impl. of the 4.3BSD OS, Leffler, McKusick, Karels,
Quarterman; '89 printing, ISBN 0-201-06196-1, chapeter 7, page 198
"Optimizing Storage Utilization", and 203 "Filesystem Data Structures", and
a few more sections of chapeter 7.  Any mistakes or misconceptions are mine
and mine alone, not that of the authors)
--
           [e-mail]              "Security for Unix is like
      Josh_Osborne@Real_World,The          Multitasking for MS-DOS"
      "The dyslexic porgramer"                  - Kevin Lockwood
We all agree on the necessity of compromise.  We just can't agree on
when it's necessary to compromise.       - Larry Wall