Re: [UPDATE][13/24]ext3 enlarge file size

Andreas Dilger <[email protected]>
Newsgroups gmane.comp.file-systems.ext2.devel,gmane.linux.kernel
Message-ID <[email protected]>
On May 30, 2006  21:25 +0900, [email protected] wrote:
> > >  	/* This constant is calculated to be the largest file size for a
> > >  	 * dense, 4k-blocksize file such that the total number of
> > >  	 * sectors in the file, including data and all indirect blocks,
> > >  	 * does not exceed 2^32. */
> > > +	if (sizeof(blkcnt_t) < sizeof(u64)) {
> > > +		upper_limit = 0x1ff7fffd000LL;
> > > +	}
> > > +	/* With CONFIG_LSF on, file size is limited to blocksize*(4G-1) */
> > > +	else { 
> > > +		upper_limit = (1LL << (bits + 32)) - (1LL << bits);
> > > +	}
> > 
> > This doesn't take into account that there will be some number of extra
> > blocks on the file for {dt}indirect blocks.  There was some discussion
> > among ext3 developers to use another field in the inode to allow the
> > i_blocks count to grow up to 2^48 bits in conjunction with this
> > patch, which will remove any worry about additional metadata blocks
> > and also allow future growth without yet another COMPAT flag.
> 
> I'm considering using l_i_frag and l_i_fsize as the high bits of
> i_blocks for 48-bits, besides i_blocks in fs blocksize.  Is there any
> comment?

Ted or Stephen, would you care to comment?  These are the same fields
used by the earlier patch "Pushing ext3 file size limits beyond 2TB"
by Goldwyn Rodrigues <[email protected]>.  Having this under
the same RO_COMPAT_HUGE_FILE makes a lot of sense.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.