Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #30732
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Shutdown behavior and flash storage devices |
| Date | 2021-07-25 14:18 +0300 |
| Organization | TGI |
| Message-ID | <sdjh9u$4oh$1@dont-email.me> (permalink) |
| References | <sdhb29$ibh$1@gioia.aioe.org> <sdidmc$d9c$1@dont-email.me> |
On 7/25/2021 4:10, Don Y wrote: > On 7/24/2021 8:19 AM, Dave Nadler wrote: >> Hi All - I'm wondering what other folks do about this issue... >> >> Consumer flash storage devices (USB memory stick, SD card, etc) >> have a nice internal wear-leveling controller. When one does a write >> operation, lots of sectors may be internally rejiggered to provide >> uniform wear (so things that are never rewritten from the application >> point of view are actually moved around and rewritten). This activity >> is invisible from normal application's point of view, but takes some >> time. If the device is powered off during such activity, data >> corruption... So, its necessary to provide the device some time after >> the last write before it is powered off. Plenty of embedded stuff I've >> seen too often corrupts memory at power off, and of course the device >> manufacturers blame the memory manufacturers... >> >> So, how do you avoid this kind of corruption in your designs? > > Two (transient) copies of each "chunk" of data. Update the second > copy (on or before impending power fail). When complete, toggle > a pointer to reference it as the most recent (assuming you don't > have metadata that automatically provides that sort of information). > > The "first" copy can now be removed and its space reallocated to > some other "second copy" > > Then, move on to the next "chunk". Design your algorithms so that > you can tolerate some chunks being "stale" (not updated in time) > wrt the others. Don, this strategy is obviously good (standard?) for say disk writes etc., but I don't know if it will be OK for flash as it involves erase then write, AFAIK "erase" is the most killing part. Perhaps they do a lot of "refresh", i.e. read while they can then rewrite the same locations? I don't really know, just wondering how they do it.
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Shutdown behavior and flash storage devices Dave Nadler <drn@nadler.com> - 2021-07-24 11:19 -0400
Re: Shutdown behavior and flash storage devices Theo <theom+news@chiark.greenend.org.uk> - 2021-07-24 16:37 +0100
Re: Shutdown behavior and flash storage devices Don Y <blockedofcourse@foo.invalid> - 2021-07-24 18:10 -0700
Re: Shutdown behavior and flash storage devices Dimiter_Popoff <dp@tgi-sci.com> - 2021-07-25 14:18 +0300
Re: Shutdown behavior and flash storage devices Don Y <blockedofcourse@foo.invalid> - 2021-07-25 09:20 -0700
Re: Shutdown behavior and flash storage devices Dave Nadler <drn@nadler.com> - 2021-07-25 08:49 -0400
Re: Shutdown behavior and flash storage devices Don Y <blockedofcourse@foo.invalid> - 2021-07-25 09:30 -0700
Re: Shutdown behavior and flash storage devices Dimiter_Popoff <dp@tgi-sci.com> - 2021-07-25 22:51 +0300
Re: Shutdown behavior and flash storage devices Don Y <blockedofcourse@foo.invalid> - 2021-07-25 13:27 -0700
Re: Shutdown behavior and flash storage devices Dimiter_Popoff <dp@tgi-sci.com> - 2021-07-26 00:00 +0300
Re: Shutdown behavior and flash storage devices Don Y <blockedofcourse@foo.invalid> - 2021-07-25 17:35 -0700
Re: Shutdown behavior and flash storage devices kegs@provalid.com (Kent Dickey) - 2021-07-25 13:53 -0500
Re: Shutdown behavior and flash storage devices Don Y <blockedofcourse@foo.invalid> - 2021-07-25 13:20 -0700
Re: Shutdown behavior and flash storage devices Jaded Hobo <badboy@heaven.org> - 2021-07-27 19:44 +0200
Re: Shutdown behavior and flash storage devices Don Y <blockedofcourse@foo.invalid> - 2021-07-27 11:27 -0700
csiph-web