Re: Android 6 internal vs SD storage

From	Paul <nospam@needed.invalid>
Newsgroups	comp.mobile.android, alt.comp.os.windows-10, alt.comp.os.windows-11
Subject	Re: Android 6 internal vs SD storage
Date	2026-08-16 23:19 -0400
Organization	A noiseless patient Spider
Message-ID	<115tuja$m4u7$1@dont-email.me> (permalink)
References	(5 earlier) <neblooF78vkU1@mid.individual.net> <115qvdq$3q0ho$1@dont-email.me> <q5m38ldne6644rosugpdkmm3p75siavr4i@4ax.com> <115sr4l$bibr$1@dont-email.me> <7eo48lt8qv3i9iallem0aooe1gkmuo44v5@4ax.com>

Cross-posted to 3 groups.

Show all headers | View raw

On Sun, 8/16/2026 9:26 PM, micky wrote:
> In comp.mobile.android, on Sun, 16 Aug 2026 13:13:58 -0400, Paul
> <nospam@needed.invalid> wrote:
> 
>> On Sun, 8/16/2026 11:52 AM, micky wrote:
>>
>>> But I think I'd be a fool to rely on this SD card, right?   I know
>>> formating is supposed to find all the bad spots, and list their
>>> locations so they are not used, but would you guys use this SD card for
>>> anything important?   

>>   https://www.reddit.com/r/raspberry_pi/comments/ex7dvo/quick_reminder_that_sd_cards_with_wearleveling/>>
>> Summary: If you device isn't healthy... don't use it.
> 
> I didn't understand most of what you wrote, but I bought a new SD card.
> 4x as big, too. 

The Reddit thread, mentions an SD Association utility for
working on an SD. The people in the thread claim, it
"changes the device capacity", which means a block of flash
is getting disabled, or there is some mechanism other
than $BADCLUS, for marking off bits of the device.

But if one section of device fails, what condition are
the other sections in ? Should we take a chance on that ?

It is the same chance we take, when moving a partition
on a hard drive, to the "unworn" part of the disk. Is
that a good idea ? There, you rely on your field
statistics. Drives can hold on for a good long time,
and if you are babying the device, you can actually
note the thing going downhill. (For example, I could
see 300 reallocations after a major data change on the disk.)
You can stop using the device, if you know when it is
going to cut out. I actually followed a hard drive
downhill, until its functional status changed. If
the reallocated max is 5500 sectors, the device stops
working at exactly half that number. You're not
allowed to do any more writes to the disk, once
it gets to half of that number. You don't actually
have 5500 to burn up. And I ruined a device on purpose,
to get that information.

If you're using a storage device, and the behavior
is known, maybe you can "use them up" like that, and
transfer off just before they crash for good.

If on the other hand, there isn't enough data to tell
you how the thing is working, then replacing it promptly
is also an option.

If you buy one with Wear Leveling, it should last a lot
longer. The SD is unlikely to have a TRIM command, so
this means the internal TRIMming is done by some other
(not as good) technique. That's also a feature of SSDs.
If your OS does not send TRIM commands, that's OK,
as the device has a fall back it uses internally.

     600  590  580  585  590      Average about ~585 or so, of write cycles
     blk  blk  blk  blk  blk      Maybe weekly TRIM helps with this

     600  550  575  565  590      Maybe the average is a bit lower...
     blk  blk  blk  blk  blk      when the internal mechanism is used

600 is a location that is "worn out" (600 write cycles).

The other locations are less worn. If we discarded the second
device there, the 550 location, we have 50 writes remaining for that
block (that's if the device would even talk to us, the assumption is
that it has stopped working).

TRIM uses knowledge of where actual files are stored, to "tell"
the storage device, which locations do not require flash backing and
can go back into the "free pool" of blocks.

When the internal mechanism is used, and no TRIM commands
tell the drive the situation, the drive can still manage some
amount of leveling, just not as good as with TRIM.

Without any wear leveling at all, if you keep writing the
MBR sector over and over and over again, the MBR fails first,
and gobs of potential write capability are thrown away when
the device is tossed in the garbage. That's how my
dead USB sticks treated me. A spot burned into them apparently,
and the devices, unrecoverable. A $3 stick, does not wear level.

   Paul

Thread

Android 6 internal vs SD storage Mike Easter <MikeE@ster.invalid> - 2026-08-14 15:23 -0700
  Re: Android 6 internal vs SD storage VanguardLH <V@nguard.LH> - 2026-08-14 20:33 -0500
    Re: Android 6 internal vs SD storage Maria Sophia <mariasophia@comprehension.com> - 2026-08-14 17:47 -0800
    Re: Android 6 internal vs SD storage micky <NONONOmisc07@fmguy.com> - 2026-08-14 22:37 -0400
      Re: Android 6 internal vs SD storage micky <NONONOmisc07@fmguy.com> - 2026-08-14 22:46 -0400
        Re: Android 6 internal vs SD storage Maria Sophia <mariasophia@comprehension.com> - 2026-08-14 20:12 -0800
      Re: Android 6 internal vs SD storage Nuno Silva <nunojsilva@invalid.invalid> - 2026-08-15 09:34 +0100
        Re: Android 6 internal vs SD storage micky <NONONOmisc07@fmguy.com> - 2026-08-15 10:23 -0400
          Re: Android 6 internal vs SD storage "Carlos E. R." <robin_listas@es.invalid> - 2026-08-15 19:25 +0200
            Re: Android 6 internal vs SD storage Nuno Silva <nunojsilva@invalid.invalid> - 2026-08-16 01:14 +0100
              Re: Android 6 internal vs SD storage "Carlos E. R." <robin_listas@es.invalid> - 2026-08-16 11:06 +0200
              Re: Android 6 internal vs SD storage micky <NONONOmisc07@fmguy.com> - 2026-08-16 11:52 -0400
                Re: Android 6 internal vs SD storage Paul <nospam@needed.invalid> - 2026-08-16 13:13 -0400
                Re: Android 6 internal vs SD storage micky <NONONOmisc07@fmguy.com> - 2026-08-16 21:26 -0400
                Re: Android 6 internal vs SD storage Paul <nospam@needed.invalid> - 2026-08-16 23:19 -0400
      Re: Android 6 internal vs SD storage Steve Hayes <hayesstw@telkomsa.net> - 2026-08-17 08:32 +0200
  Re: Android 6 internal vs SD storage Mike Easter <MikeE@ster.invalid> - 2026-08-14 19:55 -0700
    Re: Android 6 internal vs SD storage Nuno Silva <nunojsilva@invalid.invalid> - 2026-08-15 09:25 +0100
      Re: Android 6 internal vs SD storage Mike Easter <MikeE@ster.invalid> - 2026-08-15 09:54 -0700
        Re: Android 6 internal vs SD storage Maria Sophia <mariasophia@comprehension.com> - 2026-08-15 09:22 -0800
          Re: Android 6 internal vs SD storage Maria Sophia <mariasophia@comprehension.com> - 2026-08-15 10:12 -0800
    Re: Android 6 internal vs SD storage Jim Jackson <jj@franjam.org.uk> - 2026-08-15 10:59 +0000
  Re: Android 6 internal vs SD storage "s|b" <me@privacy.invalid> - 2026-08-15 19:48 +0200
    Re: Android 6 internal vs SD storage Mike Easter <MikeE@ster.invalid> - 2026-08-15 11:48 -0700

csiph-web