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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
