On Fri, Sep 16, 2011 at 2:45 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > 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? Nope, regarding resize group desc is better than exclude inode. For meta_bg, group desc is much more welcome. Yongqiang. > > Amir. > -- Best Wishes Yongqiang Yang -- 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
