By default, makefs(8) has very few spare inodes in its output images, which is fine for static filesystems, but not so great for VM images where many more files will be added. Make makefs(8) use the same default settings as newfs(8) when creating images with free space -- there isn't much point to leaving free space on the image if you can't put files there. If no free space is requested, use current behavior.
This appears to be the source of the discrepancy between newfs and makefs:
sbin/newfs/mkfs.c 338: density = MAX(NFPI, minfragsperinode) * fsize; 341: density = minfragsperinode * fsize; usr.sbin/makefs/ffs.c 429: ffs_opts->density = fsopts->size / fsopts->inodes + 1; usr.sbin/makefs/ffs/mkfs.c 138: density = ffs_opts->density;
Fixing this here too for older makefs building images from newer sources might be reasonable, but I wonder if makefs should be made a bootstrap tool instead, along with its default being improved.
So makefs(8), by default, creates a file system that can exactly hold the input tree (no extra space, no extra inodes, no extra anything). If we change the defaults in makefs(8), it seems like there are a few options:
- Unconditionally allocate extra inodes. I'm not sure this makes sense to leave inodes around in a universe where the default is no extra space.
- If the user asks for extra space, add extra inodes as well, using the same default density as newfs(8) does.
The latter is nice in some ways (no obvious POLA issues, at least), so I think I prefer it. growfs adds extra inodes if the filesystem is later expanded, so that should be fine as well. I can rework this patch to do that; I can also commit this now as a stopgap since it is less work and should be functionally equivalent so that users don't have to wait.