Re: fallocate support for bitmap-based files

[Mingming Cao <cmm@us.ibm.com>]

On Sat, 2007-06-30 at 13:29 -0400, Andreas Dilger wrote:
> On Jun 30, 2007  10:13 -0400, Mingming Cao wrote:
> > Another approach we have been thinking  is using a backing
> > inode(per-inode-with-preallocation) to store the preallocated blocks.
> > When user asked for preallocation on the base inode, ext2/3 create a
> > temporary backing inode, and it's (pre)allocate the corresponding
> > blocks in the backing inode. 
> > 
> > When writes to the base inode, and realize we need to block allocation
> > on, before doing the fs real block allocation, it will check if the file
> > has a backing inode stores some preallocated blocks for the same logical
> > blocks.  If so, it will transfer the preallocated blocks from backing
> > inode to the base inode.
> > 
> > We need to link the two inodes in some way, maybe store the backing
> > inode number via EA in the base inode, and flag the base inode that it
> > has a backing inode to get preallocated blocks.
> > 
> > Since it doesn't change the block mapping on the original file until
> > writeout, so it doesn't require a incompat feature to protect the
> > preallocated contents to be read in "old" kernel. There some work need
> > to be done in e2fsck to understand the backing inode.
> 
> I don't know if you realize, but this is half-way to supporting
> snapshots within the filesystem.  

>From your description it seems similar, but not sure if it's half-way
yet. Just to clarify: What's stored in the backing inode(in the
preallocation case) is just metablocks, not data blocks. The transfer
(from backing inode to the base inode) do not involve any data blocks
migration.

Another comment, if we seriously looking for supporting preallocation in
ext2 in upstreeam, I'd like to choose a solution suitable for ext3 as
well. Taking a bit from block number to flag preallocated blocks means
reduce ext2/3 fs limit to 8TB, which probably not a big deal for ext2,
but not so good for ext3.

Mingming