Le 03/07/2014 16:54, Nicolas Ecarnot a écrit : Hi, Should I ask this question on the dev mailing-list? -- Nicolas Ecarnot

----- Original Message ----- You can change it but it's not going to affect the lvm behavior in VDSM since we don't use the host lvm config file. This will be probably addressed as part of bz1017284 as we're considering to extend discard also to vdsm images (and not direct luns only). https://bugzilla.redhat.com/show_bug.cgi?id=1017284 -- Federico

On 07/22/2014 07:21 PM, Nicolas Ecarnot wrote: fixed, but its currently mostly a place holder titled: Bug 1017284 - [RFE] Add SCSI discard support for DirectLUN disks sitting on a virtio-scsi controller

Hi Nicolas, you can find more information on this at: https://bugzilla.redhat.com/show_bug.cgi?id=981626 First of all an important note (that was already mentioned): vdsm is not using lvm.conf, so whatever change you make there it won't affect vdsm behavior. Anyway long story short, enabling issue_discards in lvm would lead to lvm commands starvation when the lv that you're removing is large and the granularity is small. The correct solution is to use blkdiscard on the lv and I happened to submit a patch series for that yesterday: http://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:... (very much experimental) The approach is to begin with issuing blkdiscard when "wipe after delete" is selected on the disk. That is because blkdiscard in the majority of the cases will wipe the lv data and I know that someone in the past has been brave enough to try and recover data from a mistakenly removed lv that wasn't post-zeroed. Anyway extending the support to non post-zero is trivial and it's just a matter of agreement and expectations. With regard to the legitimate question of why both post-zero and block discard, the answer is that after discussing it with storage array experts it seems that blkdiscard has no contract in guaranteeing that the data will be blanked out and it could later on show up even on a completely different LUN of the same storage. -- Federico ----- Original Message -----