[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