Re: Permanently change thin provisioning method from user space?

[Andrei Borzenkov <arvidjaar@gmail.com>]

28.06.2017 00:01, Ewan D. Milne пишет:
> On Tue, 2017-06-27 at 14:02 +0300, Andrei Borzenkov wrote:
>> I'm facing storage system that while generally advertising support for
>> WRITE_SAME_16 with UNMAP in reality fails this request depending on
>> exact volume configuration. This configuration is done on storage side
>> and may happen after host initially discovered LUN.
>>
>> I though about simply overriding kernel auto-detect with UNMAP using
>> sysfs scsi_disk/.../provisioning_mode attribute, but it appears kernel
>> may re-evaluate it in some cases, so changes do not stick. Is it
>> possible to permanently restrict it per-device (or per-vendor/device)?
>>
>> TIA
>>
>> -andrei
> 
> sd_fops->revalidate_disk() will cause the properties that cause the
> provisioning_mode to be evaluated to be re-read, and sd_config_discard()
> to set the determined mode.  We might want to re-think this, since the
> user overrode what was probed earlier.  However, we might also want to
> automatically handle the storage capabilities changing, so I'm not sure.
> 

Will revalidate_disk() emit "change" event? If yes, it can be handled by
udev rule (although small race window probably will still exist).

> I think we should figure out how best to handle devices/arrays that aren't
> correctly handling WRITE SAME(16) w/UNMAP,


In this case it caused total multipath outage because it tried DISCARD
on every path and failed all of them in turn.