[Users] ploop ext4 reserved_ratio

[Jonathan Wright]

Please disregard, these are the wrong figures.  I'm having trouble 
consistently recreating it.

On 7/17/19 10:18 AM, Jonathan Wright wrote:
> This is with reserved_ratio set to 20 in /etc/mke2fs.conf for easy 
> identification of what's happening:
>
> Default 10G container:
>
> # vzctl create 9999 --ostemplate centos-7-x86_64 --diskspace 100G
> # tune2fs -l /dev/ploop43211p1 |grep -i 'block count'
> Block count:              26213888
> Reserved block count:     1074721
> This is 5%
>
> #vzctl set 9999 --diskspace 200G --save
> # tune2fs -l /dev/ploop43211p1 |grep -i 'block count'
> Block count:              52428288
> Reserved block count:     2123251
> This is still 5%
>
> Let's go back to 100G (shrink):
> #vzctl set 9999 --diskspace 100G --save
> # tune2fs -l /dev/ploop43211p1 |grep -i 'block count'
> Block count:              52428288
> Reserved block count:     1310668
>
> Now we're at 20% because that's what's set in /etc/mke2fs.conf. Note 
> total block count didn't shrink but space inside CT is only 100G.
>
> Beyond this point I'm having trouble finding steps to consistently 
> recreate the issue but at seemingly random combinations of grow/shrink 
> when doing the shrinks it will go back to whatever ratio is set in 
> /etc/mke2fs.conf.  This at least shows initially that there is an 
> issue in the form of an inconsistency.
>
> After the 20% goes into effect, it's also 20% of the total of the max 
> blocks the image has ever consumed, not 20% of the actual block size.  
> I'm not sure if this causes any issues inside the CT or not.
>
> /etc/mke2fs.conf should either always be used, or never used.
>
> On 7/17/19 5:20 AM, Igor Sukhih wrote:
>> On 7/17/19 12:21 PM, Vasily Averin wrote:
>>> Dear Jonathan,
>>> thank you for reporting the problem,
>>> we did no saw such behaviour before.
>>>
>>> In fact ploop grow should call resize2fs and probably it ignores 
>>> reserved ratio setting.
>>> You can try to run it under strace and look at details, ploop 
>>> sources are public available too.
>>>
>>> Igor (in cc:) is going to check this behaviour, I hope he will 
>>> clarify the situation soon.
>> Unable to reproduce, resize 10G to 1Tb
>>
>> 10G
>>
>> Block count:              2620928
>> Reserved block count:     131046
>>
>>
>> 1TB
>>
>> Block count:              268434944
>> Reserved block count:     10763323
>>
>>> Thank you,
>>>     Vasily Averin
>>>
>>> On 7/16/19 8:15 PM, Jonathan Wright wrote:
>>>> What seems to be happening is if you set a reserved_ratio on an 
>>>> image and grow the image, that ratio is maintained and will stay at 
>>>> that ratio.
>>>>
>>>> When shrinking the image however, mke2fs.conf is referenced and 
>>>> that's the ratio that gets used.
>>>>
>>>> Is there a reason for this behavior to be inconsistent?  I was 
>>>> incorrect about making new ploop images using mke2fs.conf - it 
>>>> seems they don't - at least not through vzctl create.  It appears 
>>>> to be hard coded at 5%.
>>>>
>>>> On 7/16/19 11:55 AM, Jonathan Wright wrote:
>>>>> ext4's default 5% reserved ratio is set on ploop images.  If you 
>>>>> update /etc/mke2fs.conf and adjust this ratio to say 1%, that's 
>>>>> used when the ploop image is created.
>>>>>
>>>>> This is great.
>>>>>
>>>>> When you then resize that image though, the stock 5% is put back 
>>>>> in place instead of the 1% that was on the filesystem (or whatever 
>>>>> might be set in /etc/mke2fs.conf).
>>>>>
>>>>> Is this intentional functionality for some reason, a bug, or 
>>>>> something simple no one has tried before?
>>>>>
>> _______________________________________________
>> Users mailing list
>> Users at openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>
-- 
Jonathan Wright
KnownHost, LLC
https://www.knownhost.com