[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4DB2DE3E.2090704@redhat.com>
Date: Sat, 23 Apr 2011 09:12:14 -0500
From: Eric Sandeen <sandeen@...hat.com>
To: i@...y.li
CC: Robin Dong <sanbai@...bao.com>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] fix incorrect error-message of ext2
On 4/23/11 9:23 AM, Coly Li wrote:
> On 2011年04月23日 21:36, Robin Dong Wrote:
>> From: Robin Dong <sanbai@...bao.com>
>>
>> After "mkfs.ext2 -b 8192" on a new partition, I mount it with a error dmesg:
>> "error: blocksize is too small"
>> That's not correct.
>>
>
> Agree, it should be too big, or invalid block size.
>
>> Signed-off-by: Robin Dong <sanbai@...bao.com>
> [snip]
>> + hblock = bdev_logical_block_size(sb->s_bdev);
>> /* If the blocksize doesn't match, re-read the thing.. */
>> if (sb->s_blocksize != blocksize) {
>> + /*
>> + * Make sure the blocksize for the filesystem is larger
>> + * than the hardware sectorsize for the machine.
>> + */
>> + if (blocksize < hblock) {
>> + ext2_msg(sb, KERN_ERR,
>> + "error: fsblocksize %d too small for "
>> + "hardware sectorsize %d", blocksize, hblock);
>
> When a file system is mounted, the reported underlying dev logical block size may be larger than a sector size.
True, but set_blocksize will fail it:
/* Size cannot be smaller than the size supported by the device */
if (size < bdev_logical_block_size(bdev))
return -EINVAL;
Above patch is really just repeating this test.
>> + goto failed_mount;
>> + }
>> +
>> brelse(bh);
>>
>
> How about just keeping bellowed lines ? Reporting bad block size number is the behavior how Ext3 and Ext4 do.
>
>> if (!sb_set_blocksize(sb, blocksize)) {
>> - ext2_msg(sb, KERN_ERR, "error: blocksize is too small");
>> + ext2_msg(sb, KERN_ERR,
>> + "error: bad blocksize %d", blocksize);
>> goto failed_sbi;
>> }
Agreed, this change makes it consistent with ext3, and I think that it is enough.
Thanks,
-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists