Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #30732

Re: Shutdown behavior and flash storage devices

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>

Show all headers | View raw


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


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