From owner-freebsd-stable@FreeBSD.ORG Tue Jan 24 15:02:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0E9D1065675 for ; Tue, 24 Jan 2012 15:02:18 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by mx1.freebsd.org (Postfix) with ESMTP id 989B08FC17 for ; Tue, 24 Jan 2012 15:02:18 +0000 (UTC) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta14.emeryville.ca.mail.comcast.net with comcast id RSwK1i0010b6N64AET2J42; Tue, 24 Jan 2012 15:02:18 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta03.emeryville.ca.mail.comcast.net with comcast id RT2H1i00N1t3BNj8PT2HyZ; Tue, 24 Jan 2012 15:02:17 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1F845102C19; Tue, 24 Jan 2012 07:02:17 -0800 (PST) Date: Tue, 24 Jan 2012 07:02:17 -0800 From: Jeremy Chadwick To: Matthew Seaman Message-ID: <20120124150217.GA10327@icarus.home.lan> References: <201201241601.48356.jhugo@meraka.csir.co.za> <4F1EC208.5060808@infracaninophile.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F1EC208.5060808@infracaninophile.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: zpool detach pool device X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 15:02:18 -0000 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 |