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

[Sunil Mushran]

For testing, I was thinking of adding a "preferred slot" mount option.
As in, mount the volume using that slot, if possible. This will make
it easier for us to test "remove slots".

Well, not thinking. I am adding it. But let me know if you have a
better idea.

Sunil Mushran wrote:
> 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
>
> _______________________________________________
> Ocfs2-tools-devel mailing list
> Ocfs2-tools-devel at oss.oracle.com
> http://oss.oracle.com/mailman/listinfo/ocfs2-tools-devel