David Gilbert wrote:
>
>>>>>> "After" == After 5 PM please slip brain through slot in door <greywolf@defender.VAS.viewlogic.com> writes:
>
>After> You are assuming that:
>
>After> 	- minfree is 10% - I meant "full, less minfree".
>
>After> In fact, I meant "full".  As in "uid 0: write failed: No space
>After> left on device" full.  As in "You have tromped all over
>After> minfree.  Go directly to disk space hell.  Do not asm("jmpa
>After> $_start"); do not collect even 200 bytes of disk space" full.
>
>After> As in "You forgot to make /usr big enough" full.  As in "You
>After> have forgotten to delete the last five kernels from the root
>After> filesystem" full.
>
>	From somewhere back in my conciousness, I seem to remember
>that inode space is separate from disk space that holds files in the
>filesystem --- and this is a major part of the design of the Berkeley
>File System.  So... to be 'full' so that you couldn't create a file,
>the filesystem would have had to run out of inodes.  I'm no expert,
>but isn't running out of inodes almost unheard of these days?
>
>	When we were all using the last few bytes of disk space, we
>used to trim that parameter on newfs to the bone.  I certainly don't
>do it anymore.

Actually, we run into not enough inodes on a regular basis, due to a
couple of different reasons:

a) We have some tools that create multi-gigabytes of really tiny files
   in thousands of directories that completely tromp all over the
   bytes/inode assumptions

b) a large (2+GB) filesystem checks much faster when the bytes/inode
   count is dropped by using the '-i' parameter to newfs under the
   4.2 filesystem (and possibly the 4.4 filesystem as well), that it
   makes sense to raise the number of bytes/inode.  Unfortunately,
   this also makes it easier for some idiot suck up all of the inodes
   by creating thousands of zero-length files

c) We have idiots who create thousands of zero-length files.  It's almost
   enough to want to slap them with inode quotas.

-- 
--------------------------------------------------------------------------
Matt Ragan  (matt@ibmoto.com)  Motorola/IBM Somerset PowerPC Design Center
Network Administrator          Systems/Network Engineering  (512) 795-7298
9737 Great Hills Trail         Austin, Tx  78759        FAX (512) 795-7519
--------------------------------------------------------------------------