W dniu 2012-12-13 16:55, Ron Hawkins pisze:
Radoslaw,
[...]
Not only controller. Sometimes smart folks also know that. I'm not so
smart,
but I can tell you what is the relationship between physical discs and
logical
volumes in my array. I have it documented, and it can be
checked/confirmed.
[Ron Hawkins] If you are using any of the current day wide striping or thin
provisioning products from IBM, EMC and HDS then this sort of mapping will
be near impossible. The closest you'll get is the array groups that make up
the pool. If you are using any dynamic tiering products, or any of the
logical volume movement tools then you have the added complexity of not
knowing where the data has been in the past.
Yes, it depends. It can depend on things you described, but also on the
detail level. Usually you can map logical volume to the dasd array ;-)
but sometimes it you can go down into details liek raid group.
I suggest that the only safe way to erase the physical drives is to use a
technique that will explicitly overwrite the entire drive or array group.
Agreed. Although you didn't mention redirected "bad" sectors ;-)
This is still problematic for SSD as they have a similar challenge to Log
Structured Files. This is why for HDS products we recommend that you encrypt
data at rest for all your drives from the get go - HDD, SSD, and SATA.
Encryption is a matter of time and cost. The question is WHEN I will
decrypt the data, not IF. And WHEN depends on my budget (the more money
the more zombies works for me) and piece of good luck (I can guess the
key 5 min. after start or as last possible value).
So the only sure way is still flame of Mordor. ;-)
And don't forget about backups, copies, remote copies, backup of
remote copies, temporary backups, ad hoc copies, data on PCs, people...
Regards
--
Radoslaw Skorupka
Lodz, Poland
--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.
This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.
BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 0000025237, NIP: 526-021-50-88.
Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
