Date: Thu, 28 Jul 2011 16:47:21 +0100 From: "Steven Hartland" <killing@multiplay.co.uk> To: "Jeremy Chadwick" <freebsd@jdc.parodius.com> Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Questions about erasing an ssd to restore performance under FreeBSD Message-ID: <2A07CD8AE6AE49A5BAED59A7E547D1F9@multiplay.co.uk> References: <13BEC27B17D24D0CBF2E6A98FD3227F3@multiplay.co.uk> <20110728012437.GA23430@icarus.home.lan> <FD3A11BEFD064193AA24C1DF09EDD719@multiplay.co.uk> <20110728103234.GA33275@icarus.home.lan> <A6828B6CE6764E13A44B1ABF61CF3FED@multiplay.co.uk> <20110728145917.GA37805@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message -----
From: "Jeremy Chadwick" <freebsd@jdc.parodius.com>
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2A07CD8AE6AE49A5BAED59A7E547D1F9>