On Fri, Sep 16, 2011 at 12:57 AM, Ted Ts'o <tytso@xxxxxxx> wrote:
> On Thu, Sep 15, 2011 at 01:08:34PM -0600, Andreas Dilger wrote:
>> In that light, why not continue to use an inode to map the exclude bitmap
>> blocks, where the bitmap offset is (group * blocksize), instead of
>> explicitly listing all of the blocks in the group descriptor? This is
>> how the buddy bitmap works in memory only, but it could be done for the
>> exclude bitmap on disk.
>
And this exactly is how the exclude inode works, except only the DIND
block is used
for mapping, just like the resize inode.
> I seem to recall the use of an inode to map the exclude bitmap added a
> huge amount of complexity to the snapshot patches. Amir, am I
> remembering this correctly?
>
No, I am not sure this is accurate.
I think after we over viewed the e2fsprogs snapshots patch set, you
has 2 observations:
1. the largest part (in lines of code) of the e2fsprogs snapshot patch set
is related to the exclude inode/bitmap code.
2. it reminded you of resize inode too much and you didn't like that
3. There was also the issue of whether or not to allow the removal of
the exclude inode/bitmap
and then re-allocation would not be in optimal layout
In retrospect, after Yongqiang has implemented the alternative exclude
bitmap patch set
for e2fsprogs, I can say:
1. The alternative patch set is not smaller
2. It is a lot more elegant and deals with correct layout of exclude
bitmap (next to block bitmap)
3. It will be able to deal with 64bit fs (unlike exclude/resize inode)
and 64bit resize
Yongqiang, do you have anything else to add to the exclude inode vs.
group desc issue?
Amir.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
