3

In the light of emmc wearout monitoring I'm wondering about the size as displayed inside a running Linux OS. An emmc chip has an internal manager which keeps track of the usage intensity of all the different byte registers. In theory, a flash device like SSD, USB stick or emmc chip should shrink in capacity when the end of live limits are being reached.

 $ lsblk -b

.. returns the blocksizes in bytes like this:

lsblk -b

If the capacity and therefore the size of the whole emmc image goes down, does this figure update itself automatically?

Are there any other tools which can achieve a real time representation of the actual available blocksize?

Edit: After the comments from @Marcus and @Artem

An emmc driver has this virtual file system entry where an "End Of Life" indication has been implemented. If I'm not mistaken 0x02 stands for 80% loss of capacity size, 0x03 stands for 90% loss of capacity size. This is kind of late to realize your emmc is gone, so I'm searching for a way to indicate this crucial information at an earlier stage.

look at : cat /sys/class/block/mmcblk1/device/pre_eol_info

Improve this question
4
  • 4
    "byte registers": no such things in flash memory. "it should shrink in capacity": says who? It shouldn't. Commented Oct 14, 2021 at 13:13
  • 2
    No media that I'm aware of shrinks on its own - if that was the case, your OS could fail spectacularly and totally unexpectedly which could lead to all sorts of litigations and a loss of money and businesses. Commented Oct 14, 2021 at 13:15
  • 3
    If I'm not mistaken 0x01 stands for 80% loss of capacity size, 0x02 stands for 90% loss of capacity size. You're mistaken. It has nothing to do with capacity loss, which, again, simply doesn't happen. It is an estimate of percentage of lifetime reached; nothing more, nothing less. Commented Oct 14, 2021 at 13:42
  • @MarcusMüller Some additional information would have be more productive. You must understand each OP is clueless when asking a question at any given moment in life. Commented Oct 15, 2021 at 14:19

2 Answers 2

Reset to default
10

No. A device with internal wear leveling like eMMC and some flash drives will not advertise their full capacity in the first place.

So, a device may have 1536 blocks but shows only 1024 to the system. The 1024 blocks that can be accessed by the OS are never guaranteed to be the same blocks, they can be re-allocated and so on.

So, the size shown to the OS cannot be used to determine the current end-of-life status.

Improve this answer
5
  • 1
    See also: en.wikipedia.org/wiki/Wear_leveling Commented Oct 14, 2021 at 13:26
  • So,As a side question; If I'm understanding this correctly, a readback md5 sumcheck via "dd" can't be trusted? Commented Oct 14, 2021 at 13:39
  • 4
    that has absolutely nothing to do with this? can't be trusted for what? Commented Oct 14, 2021 at 13:39
  • @MarcusMüller :-). I'm happy to learn.. Commented Oct 14, 2021 at 13:40
  • 1
    @rm-rf You may detect errors in the storage when writing and reading all (visible) blocks and checking the data read back with a hash function, yes. However, this means a lot of wear by itself. Perhaps you want to open a new question like "What is the best way to detect wear leveling / EoL status on an eMMC?" (Please open a new question rather then editing this one because that could create confusion.) Commented Oct 14, 2021 at 13:42
1

Extra update after some white paper reading: (Micron)

I got mixed information from the comments combined with my own understanding so I'm trying to be as correct as I can about this.

Apparently, Every Micron emmc chip has 2% of extra memory capacity, called: Reserved blocks. 2% is the estimated lifetime degradation of the chip. ( I think this is more a marketing figure )

Every time a bad block has been detected it will be replaced by a fresh one coming from the reserved block. This is done by the internal memory manager which also balances the memory block usage to avoid wear out at specific hot spots. As a side effect an EOL would come very quickly as the memory blocks where always used with the same intensity.

So this means the memory size keeps stable from an OS perspective up to a certain point.

The Linux driver creates an entry to check the EOL estimation for an emmc device.

Look at:

cat  /sys/class/block/mmcblk1/device/pre_eol_info

There you'll find a number:

  • 0x01: Normal operation
  • 0x02: 80% of the reserved memory capacity consumed
  • 0x03: 90% of the reserved memory capacity consumed

0x03 is a critical warning for the chip. From there on the chip will consume it's capacity and will degrade very quickly.

Improve this answer
8
  • 3
    From there on the chip will consume it's capacity - The worn-out block replacement has already consumed most of the spare capacity if you've gotten to that point. Nothing will ever make the drive report itself as a smaller size to the host; that would break a filesystem that had data (and metadata) located near the end of the device. If those sector addresses are now past the end of the device, that's identical to the situation you'd be in if you used dd to copy the first 1TiB of a 2TiB drive to a smaller disk, i.e. partition warnings and filesystem errors when trying to read. Commented Oct 15, 2021 at 5:18
  • 2
    The expected mechanism would be writes on some sector returning errors instead of success. A kernel and filesystem designed to degrade gracefully could treat those as reserved and not part of the usable space anymore, but if you get a write error at all that probably means the flash controller has fully run out of working unused sectors. So more normally a USB stick or SSD firmware will put itself into a read-only mode so all writes fail. Or with bad firmware, totally brick itself and not even let you read your data. Commented Oct 15, 2021 at 5:21
  • 2
    Think of the controller in any SSD, USB stick, or anything that does wear leveling (i.e. not raw flash) as being like a file server or database engine, but for blocks instead of files, which implements the logical array of sectors that the host sees, implementing that on top of flash write blocks, larger erase blocks, and wear leveling. So it's fully virtual, no expectation that host writes to the same sector will result in a device write to the same sector, or that anything is physically contiguous. It's not like a magnetic disk with a few spare sectors for 1-off replacement. Commented Oct 15, 2021 at 5:24
  • 1
    I've only read about this for SSDs and USB flash drives; IDK anything about eMMC in particular. But it's highly likely they use the same basic design since you already said they use a full flash wear-leveling layer, not just per sector replacement. I'm not sure what firmware design choices lead to bricking; probably the firmware itself depends on being able to save some stuff to the flash. Commented Oct 15, 2021 at 8:30
  • 1
    But I've read about it happening for some drives. e.g. techreport.com/review/27909/… mentions the Intel 335 series going read-only, then bricking (intentionally?) after a power cycle, when its write endurance is exhausted. One commenter there suggests this is probably due to firmware startup failing to read necessary info from the NAND flash, not actually intentional bricking. (If the drive firmware lets flash wear out to the point where it can't read without errors, that can make sense; drives to need to persist e.g. the remapping state.) Commented Oct 15, 2021 at 8:30

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.