[Ocfs2-tools-devel] [PATCH]: Add removing slots support for ocfs2-tools

[Sunil Mushran]

tao.ma wrote:
> Sunil Mushran wrote:
>> Tao,
>>
>> 3. remove_slot_1.patch
>>
>> a. In remove_slot_check:
>> +       /* we don't allow remove_slot to coexist with other tunefs
>> +        * options to keep things simple.
>> +        */
>> Can we move this check to get_options(). Similar checks are already 
>> there.
> I originally thought of that, but in the function get_options I can't 
> get max_slots of the volume, so I can't put the check there.

This is a minor point. We can leave it as is for the time being.
In a cleanup patch, we should have a function that explicitly disallows
mixing incompatible operations in get_options() itself. In short, we
don't need the max_slots because we can disallow even the thought
of adding or reducing slots in the same pass as vol resize or
journal resize. :)

> I will wait for all your comments and try to use quilt mail, divide 
> those patches into many mails, add comments and send again. ;)
As far as relink_system_alloc() goes, my concern is that we don't
balance the chains in move chain. We want the inode_alloc (and ext_alloc)
chains to have the same number of groups, with the one off exception.

Also, it may be easier if we move chains from bottom up.

relink_system_alloc()
for (i = cl->cl_next_free_rec - 1; i >= 0; i--) {
...
move_chain_rec();
}

Also, means move_groups() will need a overhaul.

We'll first have to identify the chain to start adding to. As in,
first see if the cl_next_free_rec < cl_count. If so, start with
cl_next_free_rec and add one group to each chain in a circular
order. If cl_next_free_rec == cl_count, then scan cr->c_total
and pick the chain in which the number is less than the preceding one.
If all have the same, then start with 0.

Yes, we need to do this to avoid performance problems in the fs.
The fs assumes all chains are balanced.
===========

Wondering whether it would be easier to complete the pure relinking
of the chains and not bother neither about the inode totals nor
group details nor inode details. We can make a pass later to do that.
Will be easier for fsck too. In short, the only thing we have to
avoid is "losing" a group. Rest fsck should be able to handle.
What do you think?

=============

Rest looks good.

Sunil