Date: Fri, 28 Aug 2015 12:47:30 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: Doug Hardie <bc979@lafn.org> Cc: FreeBSD - <freebsd-questions@freebsd.org> Subject: Re: Replacing Drive with SSD Message-ID: <alpine.BSF.2.20.1508281235390.74312@wonkity.com> In-Reply-To: <CEAD84AD-341A-4FB9-A3A1-D0D5A550AFFD@lafn.org> References: <CEAD84AD-341A-4FB9-A3A1-D0D5A550AFFD@lafn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 27 Aug 2015, Doug Hardie wrote: > I am having to replace a drive with a SSD. Normally if I were > replacing it with another drive, I would hook up the new drive to the > computer and just use dd to copy everything (system would be > quiescent). Beyond copying unused blocks which can mess with wear leveling on SSDs (and wastes time on spinning drives) and blindly copying the partition tables (which goes wrong with GPT backup tables), consider that the copy is binary identical to the original. So GUID is not so "U" any more. Probably that will not cause a problem, but since dd has other problems when copying drives, best to use dump/restore for UFS or send/recv for ZFS. > Can I do the same with a SSD or does it need to be setup differently? > This is a boot drive (i.e., the only drive in the system). It *can* be done, but there are better ways. For SSDs specifically: Use GPT because it is easy to control where partitions start. Use gpart's -a flag to align to 4K blocks, or even 1M or 2M boundaries for an SSD. Enable trim with UFS. Use SU rather than SU+J with UFS. If you are a belt-and-suspenders type, create a smallish, maybe 4G, partition on the drive that will never be used and leave it empty. Don't write to it, ever. This is called over-provisioning. The drive sees that all those blocks are free and it can swap them around for wear leveling. This can be used in addition to trim.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1508281235390.74312>