enable issue_discards=1 in /etc/lvm/lvm.conf? about sm HOT 9 OPEN

It might not be unreasonable to allow this to be enabled more easily than modifying a config file, e.g. via a key in the xapi database and then customers could enable (at their own risk) to ascertain whether it works correctly in their environment.

from sm.

It is set to 0 by default due to data corruption caused by SANs that implement the discard functionality incorrectly so it isn't safe to have on by default.

The performance issue is also valid. Some SANs are understood to lock an entire LUN or RAID set in order to complete discard which is obviously undesirable with active dynamic workloads.

Even if it could be proved that neither of these issues affected any of the current storage that we have available in our test labs or storage certified on the HCL it would potentially be embarrassing to impact a customer with a previously working environment.

from sm.

Thanks. Is there a known list of such SANs?

from sm.

Thanks. Is there a known list of such SANs?

Not that I'm aware of, this predates my involvement so all I have to go on is the reasons I was given when asking the same questions of previous maintainers.

from sm.

Is that a setting that could be enabled on a per storage basis?

from sm.

Is that a setting that could be enabled on a per storage basis?

It could, by optionally passing (something like) to the lvremove command

--config devices{issue_discards=1}

this is exposed in the command api by the config_param parameter to the lvutil.remove method, so a call of lvutil.remove(<path>, config_param="issue_discards=1") would probably do the right thing.

from sm.

Would the trim plugin help here?

from sm.

That's sort of what the trim plugin does but it's a manual operation and it trims the empty space of the VG by creating an LV that fills the entire freespace and then discarding it and removing it.

from sm.

It might not be unreasonable to allow this to be enabled more easily than modifying a config file, e.g. via a key in the xapi database and then customers could enable (at their own risk) to ascertain whether it works correctly in their environment.

Any updates on that? SCSI discard is implemented for VMware IMHO and should really belog to supported features in the 21st century. It's fine if not enabled by default, but a switch via XAPI management (to be used by Xen Center/XOA...) should really be offered.

from sm.