From owner-freebsd-fs@FreeBSD.ORG Thu Jul 28 15:47:15 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF8F7106564A for ; Thu, 28 Jul 2011 15:47:15 +0000 (UTC) (envelope-from prvs=1190a6d8e6=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 30B6B8FC0C for ; Thu, 28 Jul 2011 15:47:14 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Thu, 28 Jul 2011 16:46:42 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 28 Jul 2011 16:46:42 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50014359165.msg for ; Thu, 28 Jul 2011 16:46:40 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1190a6d8e6=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-fs@FreeBSD.ORG Message-ID: <2A07CD8AE6AE49A5BAED59A7E547D1F9@multiplay.co.uk> From: "Steven Hartland" To: "Jeremy Chadwick" References: <13BEC27B17D24D0CBF2E6A98FD3227F3@multiplay.co.uk> <20110728012437.GA23430@icarus.home.lan> <20110728103234.GA33275@icarus.home.lan> <20110728145917.GA37805@icarus.home.lan> Date: Thu, 28 Jul 2011 16:47:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Questions about erasing an ssd to restore performance under FreeBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 15:47:15 -0000 ----- Original Message ----- From: "Jeremy Chadwick" > I guess the newfs(8) man page should be rephrased then. When I read the > description for the -E option, I see this paragraph: > > Erasing may take a long time as it writes to every sector > on the disk. > > And immediately think "Oh, all it does is write zeros to every LBA, > probably in blocks of some size that's unknown to me (vs. 512 bytes)". > > I can submit a PR + patch for this, but I'd propose the man page > description for -E be changed to this: > > -E Erase the content of the disk before making the filesystem. > The reserved area in front of the superblock (for bootcode) > will not be erased. > > This option writes zeros to every sector (LBA) on the disk, > in transfer sizes of, at most, 65536 * sectorsize bytes. It actually does more than this using BIO_DELETE to tell the disk its unallocated now aka (TRIM) but needs to state its only suppored on some controllers / disk drivers. > Basically remove the mention of wear-leveling and "intended for use > with flash devices". Any device can use this option as well; it's a > UFS-esque equivalent of dd if=/dev/zero of=/dev/device bs=..., sans the > exclusions mentioned. I believe it does this if its supported, which atm means ada, thats what needs clarifying. > SandForce-based SSDs have a history of being extremely good with their > GC, but I've never used one. However, if I remember right (something I > read not more than a week ago, I just can't remember where!), it's very > rare that any SF-based SSD vendor uses the stock SF firmware. They > modify the hell out of it. Meaning: two SSDs using the exact same model > of SF controller doesn't mean they'll behave the exact same. Hmm, I > probably read this on some SSD review site, maybe Anandtech. I imagine > the same applies to Marvell-based SSD controllers too. Yer quite possibly. >> Using a Backup -> Erase -> Restore direct from BSD would hence be my >> preferred workaround until TRIM support is added, but I guess that could >> well be some time for ZFS. > > Understood. I'm off work this week so I'll see if I can dedicate some > time to it. Too many non-work projects I'm juggling right now, argh. > > I'll have to start with camcontrol since the test system I have uses > ada(4) and not classic ata(4). I'm not even sure what I'm really in for > given that I've never looked at camcontrol's code before. > > If I "brick" my SSD I'll send you a bill, Steven. Kidding. :-) If you need a test SSD lmk an address offlist and I'll sort, least we can do :) Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk.