@fungi: your interpretation is correct... although I wouldn't consider "adding an option that defaults to disabled" to be an acceptable fix, and if that is our answer to an issue, then it should fall on the OSSN bucket (think "known issues and limitations").
I propose we mark this one as a dupe of the other, and that we reopen the other... but first I would like to get the consequences right. We don't zero on delete, but are we cleaning up the volume before it's given to new users ? Or do all default deployers of Cinder/LVM expect to expose stale data from previous tenants on block devices they hand out ? If the latter, I'd be tempted to change the default for secure_delete to ON and let the distros fix their kernel bug (or take the responsibility to change that option default themselves).
@fungi: your interpretation is correct... although I wouldn't consider "adding an option that defaults to disabled" to be an acceptable fix, and if that is our answer to an issue, then it should fall on the OSSN bucket (think "known issues and limitations").
I propose we mark this one as a dupe of the other, and that we reopen the other... but first I would like to get the consequences right. We don't zero on delete, but are we cleaning up the volume before it's given to new users ? Or do all default deployers of Cinder/LVM expect to expose stale data from previous tenants on block devices they hand out ? If the latter, I'd be tempted to change the default for secure_delete to ON and let the distros fix their kernel bug (or take the responsibility to change that option default themselves).