[ClusterLabs] One volume is trimmable but the other is not?
Eric Robinson
eric.robinson at psmnv.com
Mon Jan 29 13:51:10 EST 2018
> -----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.
--Eric
More information about the Users
mailing list