[Users] Snapshot merging and the effect on underlying LV metadata

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 27 Feb 2014, Davis, Richard wrote: It is my belief a depetion cannot be relied upon to have happened in all cases. Some options flag sets in lvm ** do ** persist old data, and so our security practice at PMman to treat data on removed LV's as though it persists There are published reports that instances on other public cloud providers have been deployed with 'non-wiped' drives in the 'slack space'. Why run the reputational risk? When we reclaim a LV, we perform a 'renaming' that permits to spot 'dirty' and 'scratched' instances needing wiping. [we also fill a new VG / PV with LV's indicating it needs wiping, as we do not wish to expose content if a drive is pulled and then re-used after testing when SMART errors appeared, but do not stand up to disqualify a drive] Later a cron driven process, sensitive to IO load runs. It builds a list of candidates over a day old, using 'find' and the LV name series showing it is dirty and scratched. Then in turn by LV found, it fires off a sub-task (when load is low), which in turn performs a 'niced' 'shred' operation on that LV, followed by the 'shred 'zeroing' operation. When load is too high, it sleeps for a couple of minutes, and re-tries fragment: $_shredCmd = "ionice -c 3 shred -n \ ".$_num_passes." -z ".$_working_lvm; Only when that sub-process has completed do we 'rename' and later 'remove' a given LV, to let its space re-enter the assignment pool - -- Russ herrold