On 03.07.19 07:22, James Bottomley wrote:
palo is producing corrupt filesystems because ext2 can't cope with any of the resize_inode, which is traditionally placed at blocks 3-258, being in the badblocks list. If this happens, mke2fs silently produces a corrupt filesystem image and the palo partition will eventually trigger a filesystem error. The fix is to force palo to specify -O^resize_inode to mke2fs which prevents ext2/3 from allocating a resize_inode (and thus prevents the filesystem from being resized). Signed-off-by: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> --- palo/palo.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/palo/palo.c b/palo/palo.c index 68b85cf..e088993 100644 --- a/palo/palo.c +++ b/palo/palo.c @@ -443,7 +443,11 @@ do_cdrom(int media, int kernel32, int kernel64, #define EXT2_HOLE ((MAXBLSIZE + 1) / EXT2_BLOCKSIZE) /* offset in bytes before start of hole, ext2 doesn't allow holes at - * to cover the first four blocks of the filesystem */ + * to cover the first four blocks of the filesystem + * + * Note: modern ext2/3 has a resize_inode covering blocks 3-258 so you + * must either always include the -O^resize_inode when creating the + * filesystem or define EXT2_OFFSET to (259*EXT2_BLOCKSIZE)*/ #define EXT2_OFFSET (4*EXT2_BLOCKSIZE) int @@ -502,7 +506,7 @@ do_formatted(int init, int media, const char *medianame, int partition, } } - sprintf(cmd, "mke2fs %s -b %d -l %s %s", do_format == 3 ? "-j" : "", + sprintf(cmd, "mke2fs %s -O^resize_inode -b %d -l %s %s", do_format == 3 ? "-j" : "",
What happens if we face an "old" mke2fs binary which doesn't know about this feature and thus fails? I wonder if it makes sense to add a fallback path? Helge
