Re: [Ext2-devel] [PATCH 2/9] sector_t format string

From: Mingming Cao
Date: Thu Aug 10 2006 - 17:57:10 EST


On Thu, 2006-08-10 at 18:37 +0200, Roman Zippel wrote:
> Hi,
>
> On Thu, 10 Aug 2006, Theodore Tso wrote:
>
> > Ext4 will support a 48-bit blocknumber format for extents, but I do
> > want to make ext4 suitable as a general purpose filesystem, and 32-bit
> > systems will be around for I fear far longer than people might wish.
> > So while I agree that we shouldn't go _too_ far out of our way to make
> > things efficient on 32-bit systems, if it's not that much work to
> > support a 32-bit sector_t, we ought to do it.
> >
> > So how about a compromise? We allow for a 32-bit sector_t in ext4,
> > but we drop the SECTOR_FMT, and rely on %llu and typecasts in
> > printk's. Then the only other extra hair in the filesystem code will
> > be a mount-time check to make sure we don't try to mount a large
> > filesystem on system with a 32-bit sector_t.
>
> Thanks, that's what I was hoping for. :)
> Disallowing to mount large fs without CONFIG_LBD is not a real problem and
> then also truncation is not an issue anymore (except maybe for e2fsck).
>

Just to clarify, the current code (both ext3/4) already check the
filesystem blocks number before mounting it...it fails to mount the
large device if sector_t is 32bit:

in fs/ext4/super.c:

static int ext4_fill_super (struct super_block *sb, void *data, int
silent)
{
.....
if (EXT4_BLOCKS_COUNT(es) >
(sector_t)(~0ULL) >> (sb->s_blocksize_bits - 9)) {
printk(KERN_ERR "EXT4-fs: filesystem on %s:"
" too large to mount safely\n", sb->s_id);
if (sizeof(sector_t) < 8)
printk(KERN_WARNING "EXT4-fs: CONFIG_LBD not "
"enabled\n");
goto failed_mount;
}
}
> bye, Roman
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/