Re: [RFC 7/7] ext3 blocks: convert ext3_fsblk_t to sector_t

On Fri, 2006-05-19 at 00:56 -0600, Andreas Dilger wrote:
> On May 18, 2006  17:31 -0700, Mingming Cao wrote:
> > On Thu, 2006-05-18 at 17:45 -0600, Andreas Dilger wrote:
> > > 	if ((((__u64)le32_to_cpu(es->s_blocks_count_high) << 32) |
> > > 	     le32_to_cpu(es->s_blocks_count)) >=
> > > 	    (sector_t)(~0ULL) >> (sb->s_blocksize_bits - 9)) {
> > > 		printk(KERN_ERR "EXT3-fs: filesystem too large to mount
> > > 		       safely\n");
> > > 		if (sizeof(sector_t) < 8)
> > > 			printk(KERN_WARNING"EXT3-fs: CONFIG_LBD not enabled\n");
> > > 		goto cantfind_ext3;
> > > 	}
> > 
> > Agree we should add checks at filesystem mount time, but I thought
> > Stephen was suggesting to add all sort of checks together: see if
> > CONFIG_LBD, filesystem superblock flags, extents capabilities and jbd
> > 64-bit extensions all match up? Shall we do this separately?
> 
> > Hmm, do we have the sector overflow issue with upstream right now?? As
> > ext3 filesystem blocks account in upstream right now is unsigned long
> > type, I could be wrong but I don't think we have the sector overflow
> > issue until we have >32 bit block number support on disk?
> 
> Yes, I believe we currently have an overflow issue in the vanilla kernel
> right now.  I had been worried about this for some time already (enough
> that CFS has not supported > 2TB ext3 filesystems as a result, because
> I didn't know where the corruption was coming from) but I didn't have
> enough information to work on, only some rare but serious reports of
> ext3 corruption on large filesystems, sometimes correlated to 32-bit
> systems.
> 
> What confused me is that RHEL4 had no problem with filesystems > 2TB,
> but this is because their kernels always include CONFIG_LBD.
> 
> 
> The problem is that if sector_t is a u32 (i.e. CONFIG_LBD not defined in
> the kernel) and we are using a filesystem larger than 2TB the calculation
> of the disk sector will overflow.  This is because the a device offset
> of >= 2TB is >= 2^40 bytes is >= 2^29 4kB blocks is >= 2^32 512-byte sectors
> and we overflow the sector offset and overwrite the beginning of the disk.
> 
> So, the above check could be initially added for only the 32-bit size:
> 
> 	if (le32_to_cpu(es->s_blocks_count) >
> 	    (sector_t)(~0ULL) >> (sb->s_blocksize_bits - 9)) {
> 		printk(KERN_ERR "EXT3-fs: filesystem on %s too large to mount
> 		       safely\n", sb->s_id);
> 		if (sizeof(sector_t) < 8)
> 			printk(KERN_WARNING
> 			       "EXT3-fs: CONFIG_LBD not enabled\n");
> 		goto failed_mount;
> 	}
> 
> And then when we add support for 64-bit s_blocks_count we can add that into
> the above size calculation.  This limits on the absolute maximum filesystem
> size is then 2^64 * 2^9 = 2^73 bytes = 2^61 4kB blocks = 2^57 64kB blocks
> in the end anyways, because the kernel can't address more than this without
> having more than a 64-bit sector_t.

Thanks for the clarification. This deserves a patch that is independent
of any other patches. Added this to my list of todo.

Mingming



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642