[Ocfs2-tools-devel] [PATCH]: Add removing
slots support for ocfs2-tools
Sunil Mushran
Sunil.Mushran at oracle.com
Mon Jun 11 13:48:02 PDT 2007
tao.ma wrote:
> That would be really cool and very helpful.
Emailed
> But please note that currently ocfs2 kernel only use extent_alloc:0000
> to alloc extent blocks, so even if you can let mount use different
> inode_alloc, all the extent block will be in extent_alloc:0000. So you
> have to define "OCFS2_USE_ALL_METADATA_SUBALLOCATORS" and build a
> non-standard kernel.
>
> So my current solution is a little tricky:
> 1. mount the volume and create test files using inode_alloc:0000 and
> extent_alloc:0000, umount.
> 2. Exchange the inode information between some specified inodes. e.g,
> if I want to let inode_alloc:0007 have some information, I will
> exchange the inode_alloc:0000 and inode_alloc:0007. Just swap the
> inode and don't touch the group descriptor and the corresponding "Sub
> Alloc Slot".
> 3. Run "fsck.ocfs2 -fy", this tool will modify the group descriptor
> and all the inode allocated information.
> The same process goes with extent alloc.
Not sure if we need that. The core code should be identical for
both inode_alloc and extent_alloc. And it is. So, when we test
it with inode_alloc, we are in effect testing it for extent_alloc too.
We can leave the full testing for when we enable use of all extent_allocs.
> I am still implementing the test script to test whether tunefs.ocfs2
> can works OK with multiple chains and groups.
ok.
> I also wrote a patch for adding some panic condition for tunefs.ocfs2,
> so that the tunefs.ocfs2 can panic at the specified place to check
> whether fsck.ocfs2 can works OK with the corruption.
Cool.
More information about the Ocfs2-tools-devel
mailing list