Date: Mon, 7 Oct 2013 08:07:48 -0600 From: Warner Losh <imp@bsdimp.com> To: Julian Elischer <julian@freebsd.org> Cc: usb@freebsd.org, "Julian H. Stacey" <jhs@berklix.com> Subject: Re: hot usb sticks Message-ID: <8325A99D-54C4-4EE0-968B-6605665F930F@bsdimp.com> In-Reply-To: <5252B9E4.2050208@freebsd.org> References: <201310051335.r95DZOx4004869@fire.js.berklix.net> <5250344E.2000500@quip.cz> <5252B9E4.2050208@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 7, 2013, at 7:40 AM, Julian Elischer wrote: > On 10/5/13 11:46 PM, Miroslav Lachman wrote: >> Julian H. Stacey wrote: >>> Has anyone else noticed how hot USB sticks can get when used for = backup ? >>> & also that IO errors occur after a while, which go away after a = cold reboot. >>>=20 >>> Not the whole stick, but the metal connector gets hot, so chip is >>> hotter still. Obviously one won't notice this on large plastic >>> encassed sticks, but 2 main sicks I use are: >>> sandisk 2Gig metal case "vendor" "0x0781"; "product" "0x5151"; >>> delock 8G miniature (~ 3mm of platic beyond plug) >>> "vendor" "0x05e3" "product" "0x0727" >>>=20 >>> I usually notice this when I am updating (writing) a crypted (gbde) >>> UFS file systems using port/net/rdist6 (which only rewrites updated = files). >>>=20 >>> Source data is 1,446,438 K bytes in 42,611 files so average >>> size of 34 K. But a lot of the files are really small, (~/.* config >>> & mail files etc, so as rdist will be updating each one = sequentially, >>> & each will take a read + write cycle on a stick block,& as many >>> small files will probably map to the same stick block, thats >>> some concentrated cycles. >>>=20 >>> More stick detail at >>> = http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/jhs/etc/devd/jhs.con= f=20 >>>=20 >>> Quite often I have to reboot my target host that has a stick = inserted, >>> I believe regardless of OS version on USB target host >>>=20 >>> Possibly there might be less heating when only reading (as read >>> cycles are also quicker), but mainly I'm backing up, writing. >>>=20 >>> I was thinking of making a heatsink to clamp to a USB socket on an >>> extension cable, but before that I'll try hanging a USB extension = cable >>> adjacent to a case fan. >>=20 >> I have a few USB sticks, some of them are really old (and fast!), for = example 512MB A-Data with 200x speed, or 8GB 133x. These fast sticks are = almost cool. Some cheap modern sticks are hot even if used as read-only = for booting ZFS backup server, where whole base system is on UFS USB = stick monted read-only and all writes are on ZFS partitions of 4 HDDs. = Even in this RO scenario, the hot stick died after about 2 years. Writes = on it was made about 3 times a year because of system or ports updates. >>=20 >> So in my case: newer -> cheaper -> slower -> hotter =3D shorter life. >=20 > actually, hotter is not always worse in Flash. > Warner can say more in detail but hot is good in some case while cold = is best when you put the device on the shelf. The amount of damage that a P/E cycle does to a cell often is determined = by the dwell time and temperature between program and erase. There's a = well known Arrhenius relationship here, so as the temperature gets = hotter, the effective dwell time increases, which allows more of the = damage to heal. So heat can be good in a high write scenario. However, in a low write, long retention scenario, high heat, by the same = Arrhenius factor, will lead to much shorter retention, which may have = contributed to your failure. There are certain housekeeping activities = that go on in the USB stick, typically, that will move really old data, = which causes additional writes to the flash that you are unaware of. = Also a high read work load can tax the cells, which have only so many = reads per page specified by the manufacturer. But if the errors occur while it is HOT and not while it is COLD, I'd be = suspecting an issue of construction that's to blame (eg, bad design that = works at low temps, but at high temps the electrical characteristics of = the data transmission lines change just enough to be out of spec). If it = just died, then the high temperature accelerated the aging effects = beyond the bounds of the drive firmware to cope. Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8325A99D-54C4-4EE0-968B-6605665F930F>