[lug] mkfs and large drives?

Bear Giles bgiles at coyotesong.com
Thu Jul 25 18:07:44 MDT 2002

> I'd suggest dropping the number of reserved blocks.  By default, I think 
> mkfs saves 5% of the blocks for the super-user, but those are rarely 
> used and on a 120GB partition that means 6GB wasted.

That's not why those blocks are set aside, and they are certainly
not "wasted."

The UFS and similar filesystems (including ext2/ext3) require about
5% free space for efficient operation.  This is because you want to
group the blocks in a file, and to a lesser extent the files in a
subdirectory, in approximately the same place on a disk.  With 5%
free space, this shouldn't be much of a problem.  With 1%, you might
be pushing it, but a modern large disk there may still be enough free
block for this to be acceptable.  However you'll need to experiment
a bit - I would start with 2% only drop to 1% if there's no disk

Microsoft has managed to neatly avoid this problem by never bothering
with "disk groups" and the like - allocation comes out of a single
universal pool.  That's why the systems gradually
s l o w
d  o  w  n
u   n   t   i   l
you run "defragment" on them.  (I think the NTFS uses clustering,
but I don't have a reference handy.)  There are tools to explicitly 
defragment UFS/EXT filesystems, but it's usually not a big issue since 
the data is clustered during normal operations.

While it would be possible to make all blocks available to all users,
in practice that's a bad idea since most users won't understand the
need for a bit of "fluidity."  So the kernel just hides a bit of space 
from regular users, but makes it available to the superuser who presumably 
can balance the need for keeping the disk "fluid" vs. a passing need for 
a bit more disk space.

It's also worth noting that you don't need any free sectors at all if 
your disk allocation is essentially read-only (e.g., a news spool with
fixed-size cache files).


More information about the LUG mailing list