Subject: Re: Re: Shrinking ext3 directories



On Saturday 22 June 2002 21:53, Andreas Dilger wrote:
> On Jun 22, 2002 20:33 +0200, Daniel Phillips wrote:
> > On Saturday 22 June 2002 08:56, Andreas Dilger wrote:
> > > One things of note - it is currently impossible to have a directory with
> > > an i_size larger than 2GB, because i_size_high is really i_dir_acl
> > > overloaded. Even though we don't need i_dir_acl anymore with EA's, all
> > > of the older kernels would break if they mounted such a filesystem.
> > > Whether they would be broken anyways trying to read a 2GB+ directory
> > > is another question entirely.
> >
> > I was going to ask you about that earlier - where do we lose the sign
> > bit?
>
> Well, I was thinking LFS - normally the limit is 2GB for files unless
> you have LARGEFILE set. After that the limit is much higher. I
> suppose it would be possible to implement a separate per-file limit
> on directories. There is no real reason why we can't store 4GB dir
> sizes on disk though.

OK, so we could grab 12 bits from the block if we assume directories
will max out at 4 GB, say 50-100 million entries, and don't get too
worried about 1 and 2 KB blocksize filesystems, which otherwise would
reduce us to 10 bits.

But the only thing standing in the way of further growth is that
i_dir_acl, and it seems like a pretty flimsy barrier. The question
is, will we ever push that 50 million entry limit in Ext2/3? I bet
we will, in some specialized applications, especially if we keep
beefing up other parts of the system.

Anyway, I think 8 bits is sufficient for the coalesce for all time,
my reasoning being that as blocksize scales up, scaling up the slack
space at the same rate doesn't hurt at all. Another, v...

ery tiny
little niceness is that we can treat the 8 bits as the top 8 bits of
the block usage divided by four, uniformly from the smallest
possible blocksize on up to whatever, with no corner cases.

--
Daniel


-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/




Privacy