Date: Fri, 17 Mar 2017 11:01:37 +0100 From: Ralf Mardorf <ralf.mardorf@rocketmail.com> To: freebsd-questions@freebsd.org Subject: Re: bootable ext. USB SSD for backup Message-ID: <20170317110137.51d1f849@archlinux.localdomain> In-Reply-To: <20170317100406.b8e3d390.freebsd@edvax.de> References: <20170316194612.GA1748@c720-r314251> <33953.128.135.52.6.1489694167.squirrel@cosmo.uchicago.edu> <92024f3c-2ab3-1741-97de-36455ca56b7e@gmx.net> <20170316213722.139560c8@archlinux.localdomain> <20170317100406.b8e3d390.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 17 Mar 2017 10:04:06 +0100, Polytropon wrote: >On Thu, 16 Mar 2017 21:37:22 +0100, Ralf Mardorf via freebsd-questions >wrote: >> On Thu, 16 Mar 2017 21:11:53 +0100, Martin S. Weber wrote: >> >Toshiba is clearly underselling the disk. >> >> I don't think so, I suspect that some bytes are reserved to >> compensate borked memory locations. > >Few years ago, I read that SSDs that are sold with size n are >actually produced as size 2 * n due to high failure rate during >production... I doubt this, since the chips are selected, before used for an SSD. OTOH the German Wiki mentions that a vendor should have used off-spec chips. However, my guess about borked memory cells is a half-truth, correct seems to be that "over provisioning" is used to provide workspace for the controller. One task of the controller seemingly is to handle borked memory cells, but it seems to be used as a buffer to avoid unneeded write cycles and to organize the available space, to avoid performance issues, if less space is free on a SSD. -- On Thu, 16 Mar 2017 23:32:14 -0600 (MDT), Warren Block wrote: >(The memory units used above are actually gwibblybytes (GwB), 1012 >7.9-bit bytes per kwibblybyte (KwB), 1011 KwB per mibblybyte (MwB), >and 1010 MwB per gwibblybyte, or about fourteen thousandths short of a >dwibblyliter (DwL).) "1 dwibblyliter" also named "1 Vogon" :p
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170317110137.51d1f849>