[ClusterLabs] One volume is trimmable but the other is not?

[Klaus Wenninger]

On 01/29/2018 07:51 PM, Eric Robinson wrote:
>
>
>
>> -----Original Message-----
>> From: Klaus Wenninger [mailto:kwenning at redhat.com]
>> Sent: Friday, January 26, 2018 11:38 AM
>> To: users at clusterlabs.org
>> Subject: Re: [ClusterLabs] One volume is trimmable but the other is not?
>>
>> On 01/26/2018 07:45 PM, Eric Robinson wrote:
>>>>> I sent this to the drbd list too, but it’s possible that someone
>>>>> here may know.
>>>>>
>>>>>
>>>>>
>>>>> This is a WEIRD one.
>>>>>
>>>>>
>>>>>
>>>>> Why would one drbd volume be trimmable and the other one not?
>>>>>
>>>> iirc drbd stores some of the config in the meta-data as well - like
>>>> e.g. some block-size I remember in particular - and that doesn't just
>>>> depend on the content of the current config-files but as well on the
>>>> history (like already connected and to whom).
>>>> Don't know if that helps in particular - just saying taking a look at
>>>> differences on the replication-partners might be worth while.
>>>>
>>>> I know that it shows the maximum discard block-size 0 on one of the
>>>> drbds but that might be a configuration passed down by the lvm layer as
>> well.
>>>> (provisioning_mode?) So searching for differences in the
>>>> volume-groups or volumes might make sense as well.
>>>>
>>>> Regards,
>>>> Klaus
>>> Thanks for your reply, Klaus. However, I don't think it's possible that anything
>> could be getting "passed down" from LVM because the drbd devices are built
>> directly on top of the raid arrays, with no LVM layer between...
>> That is why I had written "passed down" as there is LVM on top of drbd and not
>> between raid and drbd ;-)
>>
>>> {
>>>         on ha11a {
>>>                 device /dev/drbd1;
>>>                 disk /dev/md3;
>>>                 address 198.51.100.65:7789;
>>>                 meta-disk internal;
>>>         }
>>>
>>>         on ha11b {
>>>                 device /dev/drbd1;
>>>                 disk /dev/md3;
>>>                 address 198.51.100.66:7789;
>>>         meta-disk internal;
>>>         }
>>> }
>>>
>>> --Eric
>>
> You said, 
>
>>>> I know that it shows the maximum discard block-size 0 on one of the
>>>> drbds but that might be a configuration passed down by the lvm layer as
>>>> well.
> How would TRIM support get "passed down" to DRBD from LVM? TRIM support works the other way around, doesn't it? Support gets "passed up" from lower layers.

Exactly. And I'm not talking about "passing down" TRIM support there ;-)
If a layer reports TRIM support to the upper layers depends both on
the the fact if the lower layer claims to support TRIM, and on local
configuration of this layer (examples: lvm, luks, ...).
The latter is what I was referring to and what might be influenced
by configuration passed down from the layer on top - not TRIM
explicitly but something that makes the layer implicitly decide
not to support trim (e.g. additional complexity not implemented yet).
Anyway - just a few thoughts on why it might make still sense to
look at differences in upper layer ...

Regards,
Klaus
 
>
> --Eric