On Sun, 06 Jan 2019 14:43:15 +0000, Markus Robert Kessler wrote:

> The code is selfmade.
>
> And, yes, also successful pings are reported. So, there are 3 things
> that can happen: online, offline, neither / error.
>
Just checking. Personally I'd remove the success reports because
generally they're not as interesting as errors but ymmv.

> Instead the formerly used cells are marked as erased / to be re-used,
> and the new, modified content of the file will be written to a different
> location. So, all cells are stressed equally.
>
Yes, wear levelling is a standard feature of all solid state memory, but
the resilience and sophistication of its process seems to vary with the
cost of the device. What it does is to remap the relationship between
physical blocks and block IDs so that heavily used blocks, such as those
containing the free sector list on a FAT device, get their content
swapped with lower usage blocks.

One known way to wreck any SS memory device is to turn it off or unplug
it during wear levelling because this is very likely to leave the memory
in an unusable state. Its impossible to tell when the wear levelling
process is being run, so its never a good idea to yank a device out of a
camera/PDA/phone/computer/whatever or to simply pull the plug on
anything, such as an RPi, that uses solid state memory.

Always use close/eject before removing solid state memory from whatever
uses it or, if it doesn't offer this feature, do a proper shutdown and
powering it off before removing the memory device.

> But after the crash / failure, when I clicked on the "root fs"
> partition, there only popped up an error alert saying that this
> partition cannot be mounted. Same symptoms seen when the first
> Kingston crashed.
>
> And, after running a fsck / e2fsck now, there is no such partition any
> more. I can access the whole partition like 'cat /dev/sdc2 | xxd |
> less', but I only see the first 64 MB. The remaining space seems
> unavailable.
>
My guess is that you were unlucky and turned it off during wear levelling.

Sometimes reformatting the device will fully recover it, sometimes not.
That depends on exactly what the wear leveller was doing when it all went
dark: if it was in the middle of remapping the blocks holding device size
or partition data then its quite possible that a reformat will fail.

When it comes to SD cards it may be useful to be know that:

- they are cheap and probably have unsophisticated, fault intolerant wear
  levelling processes built into them, i.e pulling an SD card out of a
  powered-on device without safely unmounting and ejecting it may
  corrupt the card.

- apparently some really cheap SD cards may not use wear levelling at
  all.

- SD card memory lifetime is about 100,000 write cycles, so heavy
  rewriting reduces their life. A write every 5 secs is 242,000 writes in
  two weeks, but in the worst case if we guess 10 bytes/msg and 512byte
  logical blocks, and 4K memory pages in the SD card the OS would think
  that was 4726 block writes, and this would reduce to 590 physical page
  writes on the card assuming it internally buffers all writes.

- an 8GB card has 2 million 4K physical blocks, so even if each OS block
  write forces a physical SD card write, no single physical block should
  see more than 8 writes in two weeks.

- there are different grades of SD card. Grade 10 are meant for
  sequential streaming in video cameras and may not perform well when
  used as random access filing systems.


--
Martin    | martin at
Gregorie  | gregorie dot org

--- SoupGate-Win32 v1.05