Hello,
I was looking to sparse_super2 feature and there is some points I do not
understand in the way it is handled on fs initialisation and resize.
In ext2fs_initialize (initialize.c), the backup superblocks field is initialised
at line 437, but they were used previously when checking for overhead (at line
407) when the second value is still ~0. Could not this lead to wrong overhead
computation in some cases?
This is certainly very unlikely because of the 50 margin taken on this overhead.
As this is some chicken/egg problem, solution is not obvious. A way is perhaps
to have ext2fs_bg_has_super accepting ~0 as a group always having a backup
superblock (unless extending the number of groups to 64 bits, if such a number
of groups is reached, it will obviously be the latest so be the candidate for
the backup bg).
In case there is some other solution, there is same kind of problem in
adjust_fs_info of resize2fs.c (line 724 check for backup super block and line
839 updates the value).
Concerning adjust_fs_info I do not understand the logic of some tests concerning
update of these values:
at line 844:
if (old_fs->group_desc_count == 1)
fs->super->s_backup_bgs[0] = 1;
if (old_fs->group_desc_count == 1 &&
fs->super->s_backup_bgs[0])
fs->super->s_backup_bgs[0] = last_bg;
else if (fs->super->s_backup_bgs[1])
fs->super->s_backup_bgs[1] = last_bg;
couldn't the 2 first "if" be collapsed: if first one is true, it leads to second
one be true and if first one is false, second is also false. Or perhaps it means
it is the wrong value that is checked or initialised in second if?
For the other case (shrinking the fs) at line 856:
if (last_bg > 1 &&
old_fs->super->s_backup_bgs[1] == old_last_bg)
fs->super->s_backup_bgs[1] = last_bg;
what ensures the location where the new super block backup will be set is a free
block?
Regards,
Damien
--
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
