Re: Wear levelling on micro-sd cards

[hede]

On 27.12.2022 10:12 Tixy wrote:

You probably can't. I've not heard of removable cards supporting the
'trim' command.


I'm running Debian on some Lenovo Flex 3 Chromebook here, booting from 
SD-Card in the internal SD Slot. And fstrim is working fine on a Sandisk 
High Endurance (one of the cheapest 128 GB SD cards I could find at my 
local electronics store).


So now you've heard first hand: (some) removable cards do indeed support 
the trim command ;-)


I think it depends on the SD Card controller AND the card itself. fstrim 
doesn't work with the same SD-Card and some cheap USB-MicroSD-Adapter 
here, while other SD-Cards do not support trim even in the Chromebooks 
SD Card Slot.


hede

Re: Wear levelling on micro-sd cards

[Matthias Böttcher]

> How do I tell the card that the free space in the VG really is free?

blkdiscard

Re: Wear levelling on micro-sd cards

[Tixy]

On Tue, 2022-12-27 at 13:47 +, Tim Woodall wrote:
> On Tue, 27 Dec 2022, Tixy wrote:
> 
> > On Mon, 2022-12-26 at 21:37 +, Tim Woodall wrote:
> > > > 
> > > But now I'm concerned about disks in a raid-1. Everything gets written
> > > when the raid rebuilds.
> > > 
> > > I've found fstrim - but that only seems to be for filesystems.
> > > 
> > > How do I tell the card that the free space in the VG really is free?
> > 
> > You probably can't. I've not heard of removable cards supporting the
> > 'trim' command.
> > 
> > 
> I found a issue_discards setting in lvm.conf. Set that, then created a
> LV using the remaining space and deleted it again.
> (this wasn't an sd card, was my main machine that I run in a raid-1
> configuration)
> 
> There's definitely something implemented on sd cards: fstrim works on an
> identical, working, card while it fails on my broken one.

Interesting, doing a Google search finds that SD cards do support
this... https://superuser.com/a/1554860

Though that was with an actual MMC device though, don't know about the
interfaces which now all seem to be implemented at the end of USB. In
fact the forum reply above says:

   USB to SD card adapters ("SD card readers") could support this
   command by advertising the TRIM or UNMAP commands via the USB
   storage interface, and translating these to the MMC_ERASE command,
   but I've yet to find a USB adapter which does this.
   
-- 
Tixy

Re: Wear levelling on micro-sd cards

[Tim Woodall]

On Tue, 27 Dec 2022, Tixy wrote:


On Mon, 2022-12-26 at 21:37 +, Tim Woodall wrote:



But now I'm concerned about disks in a raid-1. Everything gets written
when the raid rebuilds.

I've found fstrim - but that only seems to be for filesystems.

How do I tell the card that the free space in the VG really is free?


You probably can't. I've not heard of removable cards supporting the
'trim' command.



I found a issue_discards setting in lvm.conf. Set that, then created a
LV using the remaining space and deleted it again.
(this wasn't an sd card, was my main machine that I run in a raid-1
configuration)

There's definitely something implemented on sd cards: fstrim works on an
identical, working, card while it fails on my broken one.

Re: Wear levelling on micro-sd cards

[Tixy]

On Tue, 2022-12-27 at 11:31 +0100, Nicolas George wrote:
> Tixy (12022-12-27):
> > The card could know what blocks of flash have been written to, it's the
> > thing that has done the writing.
> 
> Indeed. And as I said already, unless the card is pathologically
> underused

You said 'unless the card is brand new'

> , “what blocks of flash have been written to” eventually
> becomes “all of them”.

Only in the case where the SD card has at some point been completely
full, and you maintain cases where that isn't true is 'pathological'.

Guess my storage uses are pathological then, because apart from the
extreme example of that restricted 4GB partition I use for a root
filesystem, my other 'normal' usage doesn't fill removable flash
storage either. E.g I copy images and videos from my digital cameras to
my PC then delete them from the cameras, and the backup storage on my
keyring I carry around isn't full. (Backup storage performance falls
badly as it fills, presumably due to lack off readily available erased
blocks, so that tells you to go buy a bigger flash stick :-)

-- 
Tixy

Re: Wear levelling on micro-sd cards

[Nicolas George]

to...@tuxteam.de (12022-12-27):
> For flash media, most of the time, "pathologically underused" is in my
> view "recommended state". My back-up USB stick is less than 50%. Once
> it reaches significantly more than that, I look around for one with four
> times that capacity.

Good for you. But constructors will not design cards for this niche use
case. Cards that gets almost filled are common, constructors will have
optimized their process to handle them.

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Wear levelling on micro-sd cards

[tomas]

On Tue, Dec 27, 2022 at 11:31:19AM +0100, Nicolas George wrote:

[...]

> Pathologically underused. A more typical use of a card would be “damn,
> my camera/phone/recorder tells me the card is full, I need to copy a few
> things to the cloud”.

For flash media, most of the time, "pathologically underused" is in my
view "recommended state". My back-up USB stick is less than 50%. Once
it reaches significantly more than that, I look around for one with four
times that capacity.

(And yes, it's LUKS encrypted, but I don't bother to overwrite the
whole thing with random data: a small information leak I live with).

Has served me well for many years.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Wear levelling on micro-sd cards

[Nicolas George]

Tixy (12022-12-27):
> The card could know what blocks of flash have been written to, it's the
> thing that has done the writing.

Indeed. And as I said already, unless the card is pathologically
underused, “what blocks of flash have been written to” eventually
becomes “all of them”.

So you have two options:

- Either when a card has been written in (almost) full once it stops
  being able to do wear-levelling and quickly dies.

- Or the suggestion that this is how wear-leveling works was wrong and
  based on insufficient reasoning about the mechanisms involved.

> So, if like me, you have a 64GB card, with just a 4GB partition

Pathologically underused. A more typical use of a card would be “damn,
my camera/phone/recorder tells me the card is full, I need to copy a few
things to the cloud”.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Wear levelling on micro-sd cards

[Tixy]

On Mon, 2022-12-26 at 21:26 +0100, Nicolas George wrote:
> Tixy (12022-12-26):
> > He didn't mention filesystems.
> > 
> > The controller in the card would surely know what flash blocks contain
> > data, so writing the whole card first would reserve those blocks as
> > 'in-use' leaving just a relatively small amount of spare blocks which
> > would be available for erasure and reuse the that repeated write.
> 
> Unless the card is brand new, “what flash blocks contain data” is “all
> of them”. The information whether a block is used or not used resides in
> the filesystem data structures.
> 

The card could know what blocks of flash have been written to, it's the
thing that has done the writing. Very simplistically, if the OS writes
to sector N, card has to allocate a block of flash to contain the data
for that sector. If OS writes to sector N again, card has to get an
erased block of flash to write new sector data to, then it can erase
the old block of flash which it now knows is unused. (Note blocks are
much bigger than sectors, and the data structures and algorithms for
keeping track of what's where will be proprietary 'magic'.)

So, if like me, you have a 64GB card, with just a 4GB partition
containing a filesystem, then the OS will never have written to sectors
outside that partition and the controller on the card would never have
had to allocated flash for them. Therefore it can know about 60GB of
unused flash, plus whatever extra reserve the card was manufactured
with.

What SD cards actually do in reality though, I don't know.

-- 
Tixy

Re: Wear levelling on micro-sd cards

[Tixy]

On Mon, 2022-12-26 at 21:37 +, Tim Woodall wrote:
> > 
> But now I'm concerned about disks in a raid-1. Everything gets written
> when the raid rebuilds.
> 
> I've found fstrim - but that only seems to be for filesystems.
> 
> How do I tell the card that the free space in the VG really is free?

You probably can't. I've not heard of removable cards supporting the
'trim' command.

Re: Wear levelling on micro-sd cards

[tomas]

On Mon, Dec 26, 2022 at 09:26:58PM +0100, Nicolas George wrote:
> Tixy (12022-12-26):
> > He didn't mention filesystems.
> > 
> > The controller in the card would surely know what flash blocks contain
> > data, so writing the whole card first would reserve those blocks as
> > 'in-use' leaving just a relatively small amount of spare blocks which
> > would be available for erasure and reuse the that repeated write.
> 
> Unless the card is brand new, “what flash blocks contain data” is “all
> of them”. The information whether a block is used or not used resides in
> the filesystem data structures.

It's more complicated than that. Making a file system doesn't write
to all blocks at the beginning. Unless you zero the whole disk before,
which takes significantly longer than just doing "mkfs.foo /my/device".

Then, some controllers even special-case the "all zeros to a block"
as "mark unused", so if you want to get extra sure, you'd have to
write random data to your device (that's what you do if you make an
encrypted file system and don't want your opponent to see which
blocks have been written).

Last time I tried, that took quite some time for my 1G (spinning
rust, admittedly) drive.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Wear levelling on micro-sd cards

[John Conover]

Stefan Monnier writes:
> > To test, say with a 16 GB SD, fill the SD to all except the last 1 KB,
> > and with a looping script, write 1KB of 1's to the remainder of the
> > SD, erase the "bits," then 1KB of 0's, erase the "bits", and so on;
> 
> I'm surprised.  I would have expected uSD cards, just like SSDs to rely
> mostly on a (small) amount of extra storage, i.e. the actual amount of
> NAND storage is higher than that reported as being available.
> 
> This way the uSD card knows for sure which blocks are in use and which
> ones aren't (without having to rely on things like TRIM).
>

That's true, Stefan, and most SD cards are made with a larger size of
physical memory than specified-inoperable bits can be mapped
out/replaced during product QA/test. The remaining bits can be used
for R/W, but, sooner or later, they wear out too-only delaying the
inevitable in the above test.

Quality SSDs will continue the mapping of inoperable bits through the
life cycle of the device-but requires some sort of ECC to do the real
time analysis, (archival grade SDs used to do this, but that market
has deteriorated because of the additional expense.)

John

-- 

John Conover, cono...@panix.com, http://www.johncon.com/

Re: Wear levelling on micro-sd cards

[Stefan Monnier]

> To test, say with a 16 GB SD, fill the SD to all except the last 1 KB,
> and with a looping script, write 1KB of 1's to the remainder of the
> SD, erase the "bits," then 1KB of 0's, erase the "bits", and so on;

I'm surprised.  I would have expected uSD cards, just like SSDs to rely
mostly on a (small) amount of extra storage, i.e. the actual amount of
NAND storage is higher than that reported as being available.

This way the uSD card knows for sure which blocks are in use and which
ones aren't (without having to rely on things like TRIM).


Stefan

Re: Wear levelling on micro-sd cards

[Tim Woodall]

On Mon, 26 Dec 2022, Tixy wrote:


On Mon, 2022-12-26 at 20:46 +0100, Nicolas George wrote:

John Conover (12022-12-26):

So, the more unused SD space is better, since wear leveling writes to
a "bit" that has been written to fewer times.

To test, say with a 16 GB SD, fill the SD to all except the last 1 KB,
and with a looping script, write 1KB of 1's to the remainder of the
SD, erase the "bits," then 1KB of 0's, erase the "bits", and so on;
the SD card will fail within hours to a few days, (with luck-note that
MTBF is mean time between failures, meaning that by MTBF, half will
have failed, half still running; its a stochastic/probability issue;
it does NOT mean that all are expected to last at least 6K writes.)

Doing the same test without filling to the last 1 KB, and the SD card
will last a very long time, (about 16 million total writes.)


Are you suggesting that the microcontroller of the SD card is capable of
decoding filesystem data structures to find out which sectors are
unused?


He didn't mention filesystems.

The controller in the card would surely know what flash blocks contain
data, so writing the whole card first would reserve those blocks as
'in-use' leaving just a relatively small amount of spare blocks which
would be available for erasure and reuse the that repeated write.


But now I'm concerned about disks in a raid-1. Everything gets written
when the raid rebuilds.

I've found fstrim - but that only seems to be for filesystems.

How do I tell the card that the free space in the VG really is free?


However, ff you only ever used the first few GB (say by putting a
filesystem on a partition a fraction the size of the card). Then
there's lots of unused flash blocks that can be cycled through by any
ware levelling algorithm the card implements.


Bizarrely, I ran the following without error on Saturday, however, it
seems to have had zero effect on the card and I cannot get it to work
again

  451  fdisk
  452  mke2fs -j /dev/mmcblk0p3
  453  cd /mnt
  454  ls
  455  mount -o ro /dev/mmcblk0p2 root
  456  mount /dev/mmcblk0p3 transfer/
  457  rsync -avHx root/ transfer/
  458  umount root/
  459  umount transfer/
  460  mke2fs -j /dev/mmcblk0p2

First command created mmcblk0p3

The card now seems to be completely read only. mmcblk0p2 is still there
with data. fstrim does not work after mounting one of the partitions.

Interestingly, my microSD adapter has a little read-only switch - switch
it to ro and I cannot mount mmcblk0p2.

Re: Wear levelling on micro-sd cards

[gene heskett]

On 12/26/22 13:44, Jeffrey Walton wrote:

On Mon, Dec 26, 2022 at 1:25 PM Tim Woodall  wrote:


[...]

It had a 16GB sandisk microSD card although I was only using c 3GB at
the beginning.

On 21st December the kernel remounted the card ro - but (almost)
everything continued to work - my daily backups take a snapshot (which
failed) and the daily 'I'm alive' email also failed. Both of these
generated an 'URGENT' email from my monitoring scripts. As the AP and
routing were both fine I investigated at the weekend.

What I found was the beginning of the card was unwriteable, I've not
investigated exactly how much, while the rest of the card seems
perfectly OK. I cannot, for example, change the partition table, nor can
e2fsck clear the dirty journal flag, nor could I change cmdline.txt but
my quick sampling didn't find anything else that was unwriteable.

Do these cards have wear levelling? Have I just got unlucky that it's
the start of the card that is unwriteable and so I cannot continue on
the 12GB of space that has never been part of a partition?


Yeah, SDcards wear out. I don't know if they perform wear leveling and such.

I use RPI's to test Botan, Crypto++ and OpenSSL on armel (RPI-1,
armv6), armhf (RPI-2, armv7-a) and arm64 (RPI-4, aarch64). I put a
swap file on them to avoid OOM kills when running the C++ compiler.[1]
I eat a SDcard every 6 months or so.

While I think they do wear leveling. however my busiest sd card is a 
64Gb in an rpi4b that also has a couple even bigger SSD's mounted by way 
of usb3 disk adaptors, and everything of a high traffic nature other 
than the os itself, has been moved to the SSD's. I build from git pulls 
or install 60 megs worth of linuxcnc almost daily and that traffic of 
the install goes to the u-sd card. That 64GB card was new in May 2016 
for a jessie install, the realtime kernel I built for LinuxCNC was 
installed in Feb 2020 after I'd rebuilt it for the rpi4b as it started 
out on an rpi3b. It is still working fine, and I am convinced it is 
because the wear leveling has room to play. A df report:

pi@rpi4:~ $ df
Filesystem 1K-blocks  Used Available Use% Mounted on
/dev/root   61064956  21638960  36863232  37% /
devtmpfs  959080 0959080   0% /dev
tmpfs 992872 0992872   0% /dev/shm
tmpfs 992872 67016925856   7% /run
tmpfs   5120 0  5120   0% /run/lock
tmpfs 992872 0992872   0% /sys/fs/cgroup
/dev/mmcblk0p1258095 4191432  26% /boot
/dev/sdb1  229700940 109273548 108689536  51% /media/pi/workspace
tmpfs 198572 4198568   1% /run/user/1000
/dev/sda3   91332952 57368  86593108   1% 
/media/pi/1485dff1-c61f-4bb0-a1c8-26f5201696fb

/dev/sda12573384 67468   2505916   3% /media/pi/boot12

/media/pi/workspace is a 240 GB SSD where most of the traffic goes, 
while /dev/sda2 is 9.9 GB of swap, 70 megs in use, sda is a 120GB 
kingston SSD. It has a small cyberpower ups and I have standby power so 
it does not see power failures.

uptime is:
pi@rpi4:~ $ uptime
 15:21:08 up 70 days,  2:00,  3 users,  load average: 0.02, 0.07, 0.24

The card seems perfectly healthy yet and will be 7 years old next May.
And yes, I did rather quickly destroy a 16GB card that had less than 5GB 
on it when it quit.


Will it die yet today? IDK.


And is there a way to detect pending failures like this before they
bite?


Not that I know of, smartctl is rather crippled for u-sd's but seems to 
work ok with the SSD's.



Don't know. I don't believe SDcards have SMART monitoring.

I usually wait until I get unexplained file system errors, and then
throw the card away. For me, the file system errors usually surface on
an `apt update && apt upgrade`.

Jeff

.


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Wear levelling on micro-sd cards

[Nicolas George]

Tixy (12022-12-26):
> He didn't mention filesystems.
> 
> The controller in the card would surely know what flash blocks contain
> data, so writing the whole card first would reserve those blocks as
> 'in-use' leaving just a relatively small amount of spare blocks which
> would be available for erasure and reuse the that repeated write.

Unless the card is brand new, “what flash blocks contain data” is “all
of them”. The information whether a block is used or not used resides in
the filesystem data structures.

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Wear levelling on micro-sd cards

[John Conover]

Nicolas George writes:
> John Conover (12022-12-26):
> > So, the more unused SD space is better, since wear leveling writes to
> > a "bit" that has been written to fewer times.
> > 
> > To test, say with a 16 GB SD, fill the SD to all except the last 1 KB,
> > and with a looping script, write 1KB of 1's to the remainder of the
> > SD, erase the "bits," then 1KB of 0's, erase the "bits", and so on;
> > the SD card will fail within hours to a few days, (with luck-note that
> > MTBF is mean time between failures, meaning that by MTBF, half will
> > have failed, half still running; its a stochastic/probability issue;
> > it does NOT mean that all are expected to last at least 6K writes.)
> > 
> > Doing the same test without filling to the last 1 KB, and the SD card
> > will last a very long time, (about 16 million total writes.)
> 
> Are you suggesting that the microcontroller of the SD card is capable of
> decoding filesystem data structures to find out which sectors are
> unused?
> 
> I find it rather surprising.
> 
> That implies a SD card could discard data from deleted file, defeating
> recovery tools and steganography.
> 
> If find it highly doubtful.
>

It is true that after the SD's microcontroller writes data to other
LRU bits, it will overwrite deleted data in a bit-just like VM memory,
or an HD.

The algorithm the microcontroller uses is NOT a classical "buddy
memory allocation" system, (a'la Knuth, that is used in VM memory or
HD, which store in adjacent sectors, where possible, to avoid the
latency of head moves, i.e., data fragmentation,) and is actually
quite complicated.

The function of the microcontroller is to permit LOGICAL segmentation,
but the actual storage addressing mechanism is not necessarily
segmented, (or contiguous in physical memory; likewise, the VM memory
system in a PC, that maps physical memory into logical contiguous
memory via the VM page table.)

John

-- 

John Conover, cono...@panix.com, http://www.johncon.com/

Re: Wear levelling on micro-sd cards

[debian-user]

> John Conover (12022-12-26):
> > So, the more unused SD space is better, since wear leveling writes
> > to a "bit" that has been written to fewer times.
> > 
> > To test, say with a 16 GB SD, fill the SD to all except the last 1
> > KB, and with a looping script, write 1KB of 1's to the remainder of
> > the SD, erase the "bits," then 1KB of 0's, erase the "bits", and so
> > on; the SD card will fail within hours to a few days, (with
> > luck-note that MTBF is mean time between failures, meaning that by
> > MTBF, half will have failed, half still running; its a
> > stochastic/probability issue; it does NOT mean that all are
> > expected to last at least 6K writes.)
> > 
> > Doing the same test without filling to the last 1 KB, and the SD
> > card will last a very long time, (about 16 million total writes.)  
> 
> Are you suggesting that the microcontroller of the SD card is capable
> of decoding filesystem data structures to find out which sectors are
> unused?
> 
> I find it rather surprising.
> 
> That implies a SD card could discard data from deleted file, defeating
> recovery tools and steganography.
> 
> If find it highly doubtful.

Perhaps you might want to read what e.g. wikipedia says about
wear-levelling before drawing too many more apparent conclusions about
how it works, what the conseqiences may be, and John's credibility? :)

> Regards,
> 

Re: Wear levelling on micro-sd cards

[Tixy]

On Mon, 2022-12-26 at 20:46 +0100, Nicolas George wrote:
> John Conover (12022-12-26):
> > So, the more unused SD space is better, since wear leveling writes to
> > a "bit" that has been written to fewer times.
> > 
> > To test, say with a 16 GB SD, fill the SD to all except the last 1 KB,
> > and with a looping script, write 1KB of 1's to the remainder of the
> > SD, erase the "bits," then 1KB of 0's, erase the "bits", and so on;
> > the SD card will fail within hours to a few days, (with luck-note that
> > MTBF is mean time between failures, meaning that by MTBF, half will
> > have failed, half still running; its a stochastic/probability issue;
> > it does NOT mean that all are expected to last at least 6K writes.)
> > 
> > Doing the same test without filling to the last 1 KB, and the SD card
> > will last a very long time, (about 16 million total writes.)
> 
> Are you suggesting that the microcontroller of the SD card is capable of
> decoding filesystem data structures to find out which sectors are
> unused?

He didn't mention filesystems.

The controller in the card would surely know what flash blocks contain
data, so writing the whole card first would reserve those blocks as
'in-use' leaving just a relatively small amount of spare blocks which
would be available for erasure and reuse the that repeated write.

However, ff you only ever used the first few GB (say by putting a
filesystem on a partition a fraction the size of the card). Then
there's lots of unused flash blocks that can be cycled through by any
ware levelling algorithm the card implements.

-- 
Tixy

Re: Wear levelling on micro-sd cards

[Nicolas George]

John Conover (12022-12-26):
> So, the more unused SD space is better, since wear leveling writes to
> a "bit" that has been written to fewer times.
> 
> To test, say with a 16 GB SD, fill the SD to all except the last 1 KB,
> and with a looping script, write 1KB of 1's to the remainder of the
> SD, erase the "bits," then 1KB of 0's, erase the "bits", and so on;
> the SD card will fail within hours to a few days, (with luck-note that
> MTBF is mean time between failures, meaning that by MTBF, half will
> have failed, half still running; its a stochastic/probability issue;
> it does NOT mean that all are expected to last at least 6K writes.)
> 
> Doing the same test without filling to the last 1 KB, and the SD card
> will last a very long time, (about 16 million total writes.)

Are you suggesting that the microcontroller of the SD card is capable of
decoding filesystem data structures to find out which sectors are
unused?

I find it rather surprising.

That implies a SD card could discard data from deleted file, defeating
recovery tools and steganography.

If find it highly doubtful.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Wear levelling on micro-sd cards

[John Conover]

Tim Woodall writes:
> 
> Do these cards have wear levelling? Have I just got unlucky that it's
> the start of the card that is unwriteable and so I cannot continue on
> the 12GB of space that has never been part of a partition?
>

Almost all SD cards from the major manufacturers in the last 5 years
use wear leveling.

Each "bit" can be re-written about 6K times before failures start.

So, the more unused SD space is better, since wear leveling writes to
a "bit" that has been written to fewer times.

To test, say with a 16 GB SD, fill the SD to all except the last 1 KB,
and with a looping script, write 1KB of 1's to the remainder of the
SD, erase the "bits," then 1KB of 0's, erase the "bits", and so on;
the SD card will fail within hours to a few days, (with luck-note that
MTBF is mean time between failures, meaning that by MTBF, half will
have failed, half still running; its a stochastic/probability issue;
it does NOT mean that all are expected to last at least 6K writes.)

Doing the same test without filling to the last 1 KB, and the SD card
will last a very long time, (about 16 million total writes.)

Obviously, a VM thrash is to be avoided on SD cards that are running
near capacity.

On the other hand, using an SD card for archival storage, (or backup,)
in a write once, and store STP to protect the plastic out gassing
failures, the failure rate is determined by quantum mechanics, and is
quite long, (usually quoted as in excess of a century, to 3 sigma
total recovery of data.)

SSDs have related issues, too.

John

-- 

John Conover, cono...@panix.com, http://www.johncon.com/

Re: Wear levelling on micro-sd cards

[Jeffrey Walton]

On Mon, Dec 26, 2022 at 1:25 PM Tim Woodall  wrote:
>
> [...]
>
> It had a 16GB sandisk microSD card although I was only using c 3GB at
> the beginning.
>
> On 21st December the kernel remounted the card ro - but (almost)
> everything continued to work - my daily backups take a snapshot (which
> failed) and the daily 'I'm alive' email also failed. Both of these
> generated an 'URGENT' email from my monitoring scripts. As the AP and
> routing were both fine I investigated at the weekend.
>
> What I found was the beginning of the card was unwriteable, I've not
> investigated exactly how much, while the rest of the card seems
> perfectly OK. I cannot, for example, change the partition table, nor can
> e2fsck clear the dirty journal flag, nor could I change cmdline.txt but
> my quick sampling didn't find anything else that was unwriteable.
>
> Do these cards have wear levelling? Have I just got unlucky that it's
> the start of the card that is unwriteable and so I cannot continue on
> the 12GB of space that has never been part of a partition?

Yeah, SDcards wear out. I don't know if they perform wear leveling and such.

I use RPI's to test Botan, Crypto++ and OpenSSL on armel (RPI-1,
armv6), armhf (RPI-2, armv7-a) and arm64 (RPI-4, aarch64). I put a
swap file on them to avoid OOM kills when running the C++ compiler.[1]
I eat a SDcard every 6 months or so.

> And is there a way to detect pending failures like this before they
> bite?

Don't know. I don't believe SDcards have SMART monitoring.

I usually wait until I get unexplained file system errors, and then
throw the card away. For me, the file system errors usually surface on
an `apt update && apt upgrade`.

Jeff

Wear levelling on micro-sd cards

[Tim Woodall]

This is only tangentially related to debian.

I have a really old rpi (2B model I think) running stock bullseye acting
as an access point and also a backup route to another wifi AP.

This all works beautifully and has run smoothly for a long time.

It had a 16GB sandisk microSD card although I was only using c 3GB at
the beginning.

On 21st December the kernel remounted the card ro - but (almost)
everything continued to work - my daily backups take a snapshot (which
failed) and the daily 'I'm alive' email also failed. Both of these
generated an 'URGENT' email from my monitoring scripts. As the AP and
routing were both fine I investigated at the weekend.

What I found was the beginning of the card was unwriteable, I've not
investigated exactly how much, while the rest of the card seems
perfectly OK. I cannot, for example, change the partition table, nor can
e2fsck clear the dirty journal flag, nor could I change cmdline.txt but
my quick sampling didn't find anything else that was unwriteable.

Do these cards have wear levelling? Have I just got unlucky that it's
the start of the card that is unwriteable and so I cannot continue on
the 12GB of space that has never been part of a partition?

I think the only bits of the FS that see regular writes are /var/log and
the journal. I'd prefer to keep that to maximize the chance that I have
logs when things go wrong. Is there some way to distribute these writes
around the card if there isn't wear levelling?

And is there a way to detect pending failures like this before they
bite?