Date: Thu, 4 Jul 2013 20:41:18 +0100 From: "Steven Hartland" <killing@multiplay.co.uk> To: "Jeremy Chadwick" <jdc@koitsu.org>, "mxb" <mxb@alumni.chalmers.se> Cc: freebsd-fs@freebsd.org Subject: Re: Slow resilvering with mirrored ZIL Message-ID: <43015E9015084CA6BAC6978F39D22E8B@multiplay.co.uk> References: <CABBFC07-68C2-4F43-9AFC-920D8C34282E@unixconn.com> <51D42107.1050107@digsys.bg> <2EF46A8C-6908-4160-BF99-EC610B3EA771@alumni.chalmers.se> <51D437E2.4060101@digsys.bg> <E5CCC8F551CA4627A3C7376AD63A83CC@multiplay.co.uk> <CBCA1716-A3EC-4E3B-AE0A-3C8028F6AACF@alumni.chalmers.se> <20130704000405.GA75529@icarus.home.lan> <C8C696C0-2963-4868-8BB8-6987B47C3460@alumni.chalmers.se> <20130704171637.GA94539@icarus.home.lan> <2A261BEA-4452-4F6A-8EFB-90A54D79CBB9@alumni.chalmers.se> <20130704191203.GA95642@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message -----
From: "Jeremy Chadwick" <jdc@koitsu.org>
...
> I believe -- but I need someone else to chime in here with confirmation,
> particularly someone who is familiar with ZFS's internals -- once your
> pool is ashift 12, you can do a disk replacement ***without*** having to
> do the gnop procedure (because the pool itself is already using ashift
> 12). But again, I need someone to confirm that.
Close, the ashift is a property of the vdev and not the entire pool so
if your adding a new vdev to the pool at least one of the devices in
said pool needs to report 4k sectors either natively or via the gnop
work around.
Note our ZFS code doesn't currently recognise FreeBSD 4K quirks, this is
something I have a patch for but want to enhance before committing.
> Next topic.
...
> Combine this fact with the fact that 9.1-RELEASE does not support TRIM
> on ZFS, and you now have SSDs which are probably beat to hell and back.
>
> You really need to be running stable/9 if you want to use SSDs with ZFS.
> I cannot stress this enough. I will not bend on this fact. I do not
> care if what people have are SLC rather than MLC or TLC -- it doesn't
> matter. TRIM on ZFS is a downright necessity for long-term reliability
> of an SSD. Anyway...
stable/8 also has TRIM support too now.
> These SSDs need a full Secure Erase done to them. In stable/9 you can
> do this through camcontrol, otherwise you need to use Linux (there are
> live CD/DVD distros that can do this for you) or the vendor's native
> utilities (in Windows usually).
When adding a new device to ZFS it will attempt to do a full TRIM so
this isn't 100% necessary but as some disks still get extra benefits
from this its still good if you want best performance.
...
> Next topic...
>
> I would strongly recommend you not use 1 SSD for both log and cache.
> I understand your thought process here: "if the SSD dies, the log
> devices are mirrored so I'm okay, and the cache is throw-away anyway".
While not ideal it still gives a significant boost against no SLOG, so
if thats what HW you have to work with, don't discount the benefit it
will bring.
...
>> nas# smartctl -a ada3
>> ada3: Unable to detect device type
>
> My fault -- the syntax here is wrong, I should have been more clear:
>
> smartctl -a /dev/ada{0,5}
>
> Also, please update your ports tree and install smartmontools 6.1.
> There are improvements there pertaining to SSDs that are relevant.
Also don't forget to update the disk DB using update-smart-drivedb.
Regardds
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?43015E9015084CA6BAC6978F39D22E8B>