From owner-freebsd-usb@FreeBSD.ORG Mon Oct 7 14:07:53 2013 Return-Path: Delivered-To: usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0161739F for ; Mon, 7 Oct 2013 14:07:53 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C381E2648 for ; Mon, 7 Oct 2013 14:07:52 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id u16so15206139iet.25 for ; Mon, 07 Oct 2013 07:07:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=X3fFe4ux0SYSB6G6l7z0sN6yO4pzo4AAkSEjKlGN/F4=; b=ipauVR1S7p8Za0wEePpWbKJLRvcyBb2ntxwIzRJHCwqu6Nc5PylcDAFKqEJIuoNFzf 12ZbvmgE+vzjNu7qkIt3k0ARRkouL+N3ksW9C7j6iuSPYQ1xcjjpeiAIuU7PpCJ9Pr7G QpKDmKVWVBHRrcALz7HImXl8yWhSj7aUk6qhOcDgCbXrueMBthoDVszTYExj3nrJACTV c0GefKutMXg20dDI0+DWnj9JHVYx7Zg4QRCFmMsKh3R4brUgrXXdI4Tzm8V1HXY6mmoi 4CrWLNqmo54JWd7/Fbkw+sEqviSp2vJkM96DCIq5jcgyGGj1aLxZcUIETEznmqxkYmh5 XX/A== X-Gm-Message-State: ALoCoQlEYph1eoyNeMMn+C6CiNVu2us8IWz7TVIPzwQy0i7M88KyO+WMJ2V7/zS1rPKVSc2gIVuf X-Received: by 10.50.153.16 with SMTP id vc16mr17041542igb.8.1381154870302; Mon, 07 Oct 2013 07:07:50 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id x6sm26880984igb.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Oct 2013 07:07:49 -0700 (PDT) Sender: Warner Losh Subject: Re: hot usb sticks Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <5252B9E4.2050208@freebsd.org> Date: Mon, 7 Oct 2013 08:07:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8325A99D-54C4-4EE0-968B-6605665F930F@bsdimp.com> References: <201310051335.r95DZOx4004869@fire.js.berklix.net> <5250344E.2000500@quip.cz> <5252B9E4.2050208@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1085) Cc: usb@freebsd.org, "Julian H. Stacey" X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 14:07:53 -0000 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=