On Thu, Sep 15, 2011 at 10:08 PM, Andreas Dilger <adilger.kernel@xxxxxxxxx> wrote: > On 2011-09-15, at 7:47 AM, Amir Goldstein wrote: >> On Thu, Sep 15, 2011 at 4:16 PM, Ted Ts'o <tytso@xxxxxxx> wrote: >>> On Thu, Sep 15, 2011 at 09:50:20AM +0300, Amir Goldstein wrote: >>>> -#define EXT2_FEATURE_COMPAT_EXCLUDE_INODE 0x0080 >>>> +/* #define EXT2_FEATURE_COMPAT_EXCLUDE_INODE 0x0080 not used */ >>>> +#define EXT2_FEATURE_COMPAT_EXCLUDE_BITMAP 0x0100 >>> >>> Why this change? Is it because you're already using 0x0100 in >>> shipping systems? >> >> I am using 0x80 in shipping systems and it signifies something a bit >> different then the proposed 0x100. >> >> EXCLUDE_INODE means that special inode 9 is used to reference exclude >> bitmap blocks. EXCLUDE_BITMAP means that exclude bitmap blocks are >> referenced from group descriptors. >> With this distinction it will be easier for me to make the migration. > > 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. > > The advantage of this is that it would allow the 32-bit bitmap checksums > to both fit into the group descriptor. The disadvantage is that there > is a chance this inode would become corrupted and the location of the > exclude bitmaps is lost. I don't know how serious that is (e.g. if e2fsck > could fix it by regenerating the bitmaps, or just deleting the snapshot). > > Cheers, Andreas > fsck can fix it. it just marks all blocks used by snapshot inodes. 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
