Re: extents in e2fsprogs

On Jun 19, 2006  21:55 +0100, Stephen C. Tweedie wrote:
> On Fri, 2006-06-16 at 01:47 -0700, Andreas Dilger wrote:
> 
> > > however, if the file system is using extents then we can create the new
> > > directory using extents; is it ok?
> > 
> > While this is possible, it definitely isn't desirable.
> 
> It will be inevitable at some point won't it, in order to guarantee
> success if we're running with a true >32-bit filesystem?

I was thinking to instead implement the "block-mapped extent" format that
has been proposed a few times previously.  This wasn't an issue for CFS
before, since the use of extents didn't include > 32-bit block numbers.
That said, the win from block-mapped extents is fairly small if we need
to use 64-bit block numbers (8 bytes vs. 12), but is noticable for 32-bit
block numbers (4 bytes vs. 12).

Briefly, a block-mapped extent is a new type of extent "index" (interior)
block which has a header, a series of leaf block numbers, and optionally
an ext3_extent_tail.  The actual format of the block numbers can be
64-bit, and optionally also a 32-bit format.  Having 32-bit block numbers
would allow easier conversion of a directory or old block-mapped file
to extent format if it needed to have blocks allocated beyond 16TB,
and better packing of 32-bit block numbers.

If we store 64-bit block numbers:
max_blocks = (blocksize - sizeof(struct ext3_extent_header)) / 8

If we have a tail we need to reduce max_blocks enough to leave room.

A block-mapped extent block would look like:

struct ext3_extent_header {
	__le16 eh_magic = EXT3_EXT_B32MAGIC;
	__le16 eh_entries;
	__le16 eh_max = max_blocks;
	__le16 eh_depth = 0;
	__le32 eh_generation; /* high 8 bits can be flags */
}
__le64 eb_blocks[eh_max];     /* only the first eh_entries are valid */
struct ext3_extent_tail {     /* optional, if eh_max allows it, and flagged */
	__le64 et_inum;
	__le32 et_igeneration;
	__le32 et_checksum;
}


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