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

Groups > comp.arch.embedded > #30734

Re: Shutdown behavior and flash storage devices

Show all headers | View raw

On 7/25/2021 4:18 AM, Dimiter_Popoff wrote:
> 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.

Keep a spare block (or two) that are already erased, on hand
(this cuts into the capacity of the device but not in a meaningful way).

As you need to write data to the device, select a page from the
erased block to accept your data.  When the number of "clean pages"
falls below a threshold, schedule another (free!) block to be erased.

If the erasure is interrupted, then you see the "free" block as
free-but-not-erased.

If the page write is interrupted, then you see the page as unclean
*and* the data it WANTED to contain as still residing in the
"previous" location.

There is always going to be a window in which you can get screwed
by unfortunate power cycling.  But, you can shrink this window
(at some manageable cost).

If, instead, you only perform the program/erase/write cycle
on the "parameter block" when you need to update the "parameters",
then you have to move the existing parameters into volatile storage.
Then, program/erase the block.  Then write the parameters back.
Then, verify the write.

This leaves the parameters (in volatile memory) "exposed" for a long
time -- seconds per block.  If you "set up" the write operation ahead
of time, you can trim this to a millisecond, or so.

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