Date: Tue, 24 Jan 2012 07:02:17 -0800 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: Matthew Seaman <m.seaman@infracaninophile.co.uk> Cc: freebsd-stable@freebsd.org Subject: Re: zpool detach pool device Message-ID: <20120124150217.GA10327@icarus.home.lan> In-Reply-To: <4F1EC208.5060808@infracaninophile.co.uk> References: <201201241601.48356.jhugo@meraka.csir.co.za> <4F1EC208.5060808@infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 24, 2012 at 02:36:56PM +0000, Matthew Seaman wrote: > If you're worried about leaking confidential information on old disk > drives, then a few passes with dban should render the data unrecoverable > except by heroic measures. Comments in passing: 1) A single pass of writing zeros to every LBA (which DBAN can do) is sufficient. The "multi-pass" nonsense was debunked a while back, where no data recovery company took on the challenge of recovering data from a drive that had all zeros written to every LBA. You can read the story here, and some data recovery companies' reactions: http://hostjury.com/blog/view/195/the-great-zero-challenge-remains-unaccepted http://hardware.slashdot.org/story/08/09/06/189248/the-great-zero-challenge-remains-unaccepted http://16s.us/zero/index.php 2) Folks considering debunking the above by mentioning Steve Gibson's SpinRite software should try their best to figure out what that buzzword-focused software actually does (including reading the technical paper on it; "DynaStat", whatever dude) -- but the reason it sometimes works for people is because it works on two levels -- both sector level *and* filesystem level. It does understand FAT/FAT32/NTFS and some other common ones, but not *IX filesystems (to my knowledge). 3) Folks considering using DBAN should either use DBAN 1.0.x or DBAN 2.2.6 "fixed", since the 2.x.x series has a well-established compatibility issue with many motherboards (the author chose to use a buggy version of SYSLINUX/MEMLINUX/ISOLINUX which causes this problem). The end result is a bootable CD that complains about "no configuration file". I've seen this happen on both consumer (Gigabyte) and server-grade hardware (Supermicro). Details: http://sourceforge.net/tracker/?func=detail&aid=3151269&group_id=61951&atid=498945 You can download the 2.2.6 "fixed" ISO here (which is the same software just built with a newer/bugfixed version of SYSLINUX/etc.): http://ubcdcreator.stopspazzing.com/dban/dban-2.2.6_i586-fixed.iso You can also Google for "dban-2.2.6_i586-fixed.iso" and find lots of people complaining about the same problem. It's fairly widespread. All DBAN does is write {whatever-source-you-choose} to the drive basically with dd (it's actually a separate wrapper program but it behaves identically to dd). 4) If you ever plan on re-using this drive in a system, please do not use the PRNG method or similar methods ("write random jibberish all over the drive"). This is almost guaranteed to confuse a system (ANY system) the next time you insert the disk; data is written to the MBR and partition table regions which is gobbledegook, resulting in the underlying BIOS, OS, or anything else trying to parse that data, and thus begins behaving weirdly/oddly ("what do you mean I can't partition this disk?" "Yeah, there's an HP/UX partition on this thing, right..."). I speak from personal experience on this matter. As such, I always advocate people zero their drives and not to pick the defaults. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120124150217.GA10327>