mkfs.minix misbehaves on 4GB filesystems

mkfs.minix misbehaves on 4GB filesystems

[Joshua Hudson]

[-- Attachment #1: Type: text/plain, Size: 1018 bytes --]

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.

Note that 1) I'm not on the mailing list and 2) I'm on vacation for a
week. Consider patch signed off. Have fun.

[-- Attachment #2: mkfs.minix.largedevice.patch --]
[-- Type: text/x-diff, Size: 1749 bytes --]

--- disk-utils/mkfs.minix.c.orig	2015-06-20 13:50:45.509325736 -0700
+++ disk-utils/mkfs.minix.c	2015-06-20 20:27:11.732436640 -0700
@@ -49,6 +49,9 @@
  * 06.29.11  -  Overall cleanups for util-linux and v3 support
  *              Davidlohr Bueso <dave@gnu.org>
  *
+ * 06.20.15  -  Do not infinite loop or crash on large devices
+ *              Joshua Hudson <joshudson@gmail.com>
+ *
  * Usage:  mkfs [-c | -l filename ] [-12v3] [-nXX] [-iXX] device [size-in-blocks]
  *
  *	-c for readablility checking (SLOW!)
@@ -504,9 +507,16 @@
 	super_set_nzones();
 	zones = get_nzones();
 
-	/* some magic nrs: 1 inode / 3 blocks */
-	if ( req_nr_inodes == 0 ) 
-		inodes = BLOCKS/3;
+	/* some magic nrs: 1 inode / 3 blocks for smaller filesystems,
+	 * for one inode / 16 blocks for large ones. mkfs will eventually
+	 * crab about too far when getting close to the maximum size. */
+	if ( req_nr_inodes == 0 )
+		if (BLOCKS > 2048 * 1024) /* 2GB */
+			inodes = BLOCKS/16;
+		else if (BLOCKS > 512 * 1024) /* 0.5GB */
+			inodes = BLOCKS/8;
+		else
+			inodes = BLOCKS/3;
 	else
 		inodes = req_nr_inodes;
 	/* Round up inode count to fill block size */
@@ -526,6 +536,12 @@
 	}
 
 	super_set_map_blocks(inodes);
+	if (first_zone_data() >= 65536)
+		errx(MKFS_EX_ERROR, _("First data block at %jd, which is too far"
+			" (max 65535).\n"
+			"Try specifying fewer inodes by passing -i######.\n"),
+			first_zone_data());
+			
 	imaps = get_nimaps();
 	zmaps = get_nzmaps();
 
@@ -793,6 +809,8 @@
 	} else /* fs_version == 1 */
 		if (BLOCKS > MINIX_MAX_INODES)
 			BLOCKS = MINIX_MAX_INODES;
+	if (BLOCKS > 4 + 65531 * BITS_PER_BLOCK)
+		BLOCKS = 4 + 65531 * BITS_PER_BLOCK; /* Utter maximum: Clip. */
 	setup_tables();
 	if (check)
 		check_blocks();

Re: mkfs.minix misbehaves on 4GB filesystems

[Sami Kerola]

On Sat, 20 Jun 2015, Joshua Hudson wrote:
> Note that 1) I'm not on the mailing list and 2) I'm on vacation for a 
> week. Consider patch signed off. Have fun.

Hi Joshua,

I reviewed your change, and changed couple magic numbers to be used from 
MINIX_MAX_INODES definition plus tidied up tiny coding style issues. The 
change is also available from my github branch minix.

https://github.com/kerolasa/lelux-utiliteetit/commit/9d170c877ec8c821e9c99ef4f7e37209d2d8c98c

--->8----
>From 9d170c877ec8c821e9c99ef4f7e37209d2d8c98c Mon Sep 17 00:00:00 2001
From: Joshua Hudson <joshudson@gmail.com>
Date: Sat, 20 Jun 2015 20:44:14 -0700
Subject: [PATCH] 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 | 25 +++++++++++++++++++++----
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/disk-utils/mkfs.minix.c b/disk-utils/mkfs.minix.c
index c84aed2..564f2b4 100644
--- a/disk-utils/mkfs.minix.c
+++ b/disk-utils/mkfs.minix.c
@@ -49,6 +49,9 @@
  * 06.29.11  -  Overall cleanups for util-linux and v3 support
  *              Davidlohr Bueso <dave@gnu.org>
  *
+ * 06.20.15  -  Do not infinite loop or crash on large devices
+ *              Joshua Hudson <joshudson@gmail.com>
+ *
  * Usage:  mkfs [-c | -l filename ] [-12v3] [-nXX] [-iXX] device [size-in-blocks]
  *
  *	-c for readablility checking (SLOW!)
@@ -504,9 +507,16 @@ static void setup_tables(void) {
 	super_set_nzones();
 	zones = get_nzones();
 
-	/* some magic nrs: 1 inode / 3 blocks */
-	if ( req_nr_inodes == 0 ) 
-		inodes = BLOCKS/3;
+	/* some magic nrs: 1 inode / 3 blocks for smaller filesystems,
+	 * for one inode / 16 blocks for large ones. mkfs will eventually
+	 * crab about too far when getting close to the maximum size. */
+	if (req_nr_inodes == 0)
+		if (2048 * 1024 < BLOCKS)	/* 2GB */
+			inodes = BLOCKS / 16;
+		else if (512 * 1024 < BLOCKS)	/* 0.5GB */
+			inodes = BLOCKS / 8;
+		else
+			inodes = BLOCKS / 3;
 	else
 		inodes = req_nr_inodes;
 	/* Round up inode count to fill block size */
@@ -524,8 +534,13 @@ static void setup_tables(void) {
 		if (inodes > MINIX_MAX_INODES)
 			inodes = MINIX_MAX_INODES;
 	}
-
 	super_set_map_blocks(inodes);
+	if (MINIX_MAX_INODES < first_zone_data())
+		errx(MKFS_EX_ERROR,
+		     _("First data block at %jd, which is too far (max %d).\n"
+		       "Try specifying fewer inodes by passing -i <inodes>"),
+		     first_zone_data(),
+		     MINIX_MAX_INODES);
 	imaps = get_nimaps();
 	zmaps = get_nzmaps();
 
@@ -793,6 +808,8 @@ int main(int argc, char ** argv) {
 	} else /* fs_version == 1 */
 		if (BLOCKS > MINIX_MAX_INODES)
 			BLOCKS = MINIX_MAX_INODES;
+	if (BLOCKS > MINIX_MAX_INODES * BITS_PER_BLOCK)
+		BLOCKS = MINIX_MAX_INODES * BITS_PER_BLOCK;	/* Utter maximum: Clip. */
 	setup_tables();
 	if (check)
 		check_blocks();
-- 
2.4.4

--
To unsubscribe from this list: send the line "unsubscribe util-linux" in

Re: mkfs.minix misbehaves on 4GB filesystems

[Joshua Hudson]

+       if (BLOCKS > MINIX_MAX_INODES * BITS_PER_BLOCK)
+               BLOCKS = MINIX_MAX_INODES * BITS_PER_BLOCK;     /*
Utter maximum: Clip. */

Adjustment was not quite correct. The limit constant here is 5 smaller
than the multiplication would lead you to guess (boot, super, imap,
inode, overflow).

Re: mkfs.minix misbehaves on 4GB filesystems

[Sami Kerola]

On 28 June 2015 at 01:11, Joshua Hudson <joshudson@gmail.com> wrote:
> +       if (BLOCKS > MINIX_MAX_INODES * BITS_PER_BLOCK)
> +               BLOCKS = MINIX_MAX_INODES * BITS_PER_BLOCK;     /*
> Utter maximum: Clip. */
>
> Adjustment was not quite correct. The limit constant here is 5 smaller
> than the multiplication would lead you to guess (boot, super, imap,
> inode, overflow).

Magic number 4 is added back to the commit.

https://github.com/kerolasa/lelux-utiliteetit/commit/20db4e07f75145c1eca7e8209efe0e246f480f51#diff-4c9bda8f12f6b5bb40a2181cb7bf0b89L794

-- 
Sami Kerola
http://www.iki.fi/kerolasa/