[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
chatter.
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).
Bear
More information about the LUG
mailing list