]> git.ipfire.org Git - thirdparty/util-linux.git/commit
mkfs.minix: increase maximum minix v2 and v3 file system sizes
authorJoshua Hudson <joshudson@gmail.com>
Wed, 24 Jun 2015 08:15:08 +0000 (09:15 +0100)
committerKarel Zak <kzak@redhat.com>
Thu, 30 Jul 2015 09:39:12 +0000 (11:39 +0200)
commitda41ff553a5cde7caa1b36f3e64e77ff6e8da33d
tree9a987b4adbf5c554d09b367673e3fecd0604340e
parent6b9784b442aea0b1c454d80bfabb17d0d5eee111
mkfs.minix: increase maximum minix v2 and v3 file system sizes

mkfs.minix misbehaves when attempting to create a large v2 or v3
filesystem.  I finally traced it down to attempting to create too many
inodes so that the first zone is past 65535 blocks in.  This obviously
doesn't work as the on-disk superblock says this is a 16 bit integer.

I wrote a patch that catches this, clamps to the absolute v2/v3 limit
(like it already does for v1), and sets the blocks per inode to a more
reasonable ratio when exceeding half a gigabyte.  Having a half-gig
filesystem with most files being smaller than 3k isn't really reasonable.

I suppose if you don't want to adjust inode sizes automatically you could
take that part out, and it will just crab sooner.

Given the non-attention in the code, I suspect nobody ever had cause to
try such a big minix filesystem.  Well I have my reasons involving some
deeply embedded work where ext2 would place too much strain on the
hardware.

Reviewed-by: Sami Kerola <kerolasa@iki.fi>
Signed-off-by: Joshua Hudson <joshudson@gmail.com>
disk-utils/mkfs.minix.c