Re: backup of the last group'descriptor when it is the 1st group of a meta_bg

[Yongqiang Yang <xiaoqiangnk@gmail.com>]

On Thu, Mar 29, 2012 at 12:08 AM, Andreas Dilger <aedilger@gmail.com> wrote:
> On 2012-03-27, at 8:47 AM, Yongqiang Yang wrote:
>> Hi Ted, Andreas and List,
>>
>> As Andreas pointed out last year, if the last group is the 1st group
>> in a meta bg, then its group desc has no backup.
>> With meta_bg resizing inode is useless,  I had a thought that we store
>> a backup group descriptor of the last group in the resizing inode？
>> What's your opinions?
>
> The main difficulty of referencing a backup group descriptor from the
> resize inode is that it may confuse tools that are trying to modify
> the resize inode.  Also, it is more difficult to access the block from
> userspace, since it would need to read the inode and use an extent to
> reference the block beyond 16TB.
I meant we store the backup group descriptor in resize inode itself
rather than store it in data blocks, so it does not need an extent at
all.  However, the inode is corrupted, we need patch e2fsck to let it
understand the resize inode.
>
> What about storing the 64-bit block number in the superblock?  This
> should be safe for older e2fsprogs that understand META_BG.  At worst
> the new backup group descriptor will not be updated on a resize by
> older e2fsprogs, which is no worse than not having a backup at all.
>
> I would suggest to put the backup group descriptor in the last block
> of the filesystem.  This would be in the 0th group of the metagroup.
> If the metagroup grows to have a second group, then this block is not
> needed anymore, and if both the primary (at the beginning of the group)
> and the backup (at the end of the group) are corrupted, then there is
> little chance that the data in this last group is good either...
>
> Actually, if the backup is always stored in the last block of the 0th
> group (which is itself the last group in the filesystem), there isn't
> even a need to store this location in the superblock.
Now we have 2 solutions, the 1st one is storing backup group
descriptor in resize inode itself while the 2nd one is storing backup
in the last block of the 0th block. Both need patching e2fsck because
older e2fsck does not work.  The 1st one's patch to e2fsck is much
more complicated, because only one group descriptor is stored in
resize inode itself, but the e2fsck's code reading/writing group
descriptor block. so I like the 2nd one.

Yongqiang.
>
> Cheers, Andreas
>
>
>
>
>



-- 
Best Wishes
Yongqiang Yang
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html