Messages in this thread | | | Date | Mon, 5 Jun 2006 14:13:20 -0600 | From | Andreas Dilger <> | Subject | Re: [UPDATE][12/24]ext3 enlarge blocksize |
| |
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |