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

R P Herrold herrold at owlriver.com
Thu Feb 27 19:20:27 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 27 Feb 2014, Davis, Richard wrote:

> I am being told that unless the "Wipe After Delete" option 
> is set on a vDisk, any subsequent snapshot merging of the 
> related VM will not delete LV metadata (or any data!) from 
> the volume created by the snapshot. Is this correct ? I'm 
> kinda hoping not !

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlMPkAMACgkQMRh1QZtklkSamQCgnVqEo2Kmzq9Ao8T0BCYhBTyn
aToAoIaOVGkxX3EsVghMxOtgE3RiUr9G
=rm/K
-----END PGP SIGNATURE-----



More information about the Users mailing list