Re: [UPDATE][12/24]ext3 enlarge blocksize

[Andreas Dilger <adilger@clusterfs.com>]

On Jun 05, 2006  15:13 +0200, Johann Lombardi wrote:
> On Fri, May 26, 2006 at 06:00:32AM -0600, Andreas Dilger wrote:
> > On May 25, 2006  21:49 +0900, sho@tnes.nec.co.jp wrote:
> > > @@ -1463,11 +1463,17 @@ static int ext3_fill_super (struct super
> > > +	if (blocksize > PAGE_SIZE) {
> > > +		printk(KERN_ERR "EXT3-fs: cannot mount filesystem with "
> > > +		       "blocksize %u larger than PAGE_SIZE %u on %s\n",
> > > +		       blocksize, PAGE_SIZE, sb->s_id);
> > > +		goto failed_mount;
> > > +	}
> > > +
> > >  	if (blocksize < EXT3_MIN_BLOCK_SIZE ||
> > > -	    blocksize > EXT3_MAX_BLOCK_SIZE) {
> > > +	    blocksize > EXT3_EXTENDED_MAX_BLOCK_SIZE) {
> > 
> > We may as well just change EXT3_MAX_BLOCK_SIZE to be 65536, because no other
> > code uses this value.  It is already 65536 in the e2fsprogs.
> 
> AFAICS, ext3_dir_entry_2->rec_len will overflow with a 64kB blocksize.
> Do you know how ext2 handles this?

Hmm, good question, I hadn't considered this.  One option is to just limit
rec_len to 32768 or less (16k, 8k, 4k?), and require that there be multiple
such records in a directory block.  We could additionally require that the
records don't span such a boundary, which would potentially make it easier
to validate broken entries themselves, but would slightly hurt the case
where there are many large filenames.

I suppose the reason this wasn't hit during previous 64kB block testing is
that this has always been tested in relation to IO performance and not with
metadata, so the directories were probably all single-block dirs with a
"." and ".." entry at the beginning and a 65512-byte rec_len for the rest.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.