[Modding][HowTo] Investigating Homey’s eMMC wear estimation

Questions & Help
, ,
1

Discussed with @Sharkys this requires it’s own Topic, Therefore moved.
Prerequisite: [Modding][HowTo] Guide to Jailbreak a Homey Pro 2023

Those of you having root on your Homey and rather bigger smart home (eg. >100 devices >50 apps installed) , can you check your emmc chip wear level ?

 ̶s̶u̶d̶o̶ ̶a̶p̶t̶ ̶i̶n̶s̶t̶a̶l̶l̶ ̶m̶m̶c̶-̶u̶t̶i̶l̶s̶
sudo mmc extcsd read /dev/mmcblk0 | grep -i life
sudo mmc extcsd read /dev/mmcblk0 | grep EOL

In my case :

eMMC Life Time Estimation A [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A]: 0x0b
eMMC Life Time Estimation B [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B]: 0x0b
eMMC Pre EOL information [EXT_CSD_PRE_EOL_INFO]: 0x01

Based on ChatGPT interpretation :
For many eMMCs, a value of 0x0b might indicate that the memory has reached 60-70% of its expected lifetime, but this can vary depending on the manufacturer’s specifications.
The eMMC Pre EOL information [EXT_CSD_PRE_EOL_INFO]: 0x01 suggests that the eMMC is not yet at its end-of-life stage, but it’s getting closer.

I’m running my Homey since aprox. 1st of May 2023 (replaced CM4).

I would like to compare your data as mmc-tool might be not 100% reliable estimating life span of each and every MMC.

Edit

2 Likes
2

Will do that when I receive my tool to connect my broken CM4 directly to my pc. :+1:

2 Likes
3

FYI, just connected new CM4 to the CM4-IO-BASE-A and run

sudo apt install mmc-utils
sudo mmc extcsd read /dev/mmcblk0 | grep -i life
sudo mmc extcsd read /dev/mmcblk0 | grep EOL

Results :

eMMC Life Time Estimation A [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A]: 0x01
eMMC Life Time Estimation B [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B]: 0x01
MMC Pre EOL information [EXT_CSD_PRE_EOL_INFO]: 0x01

ChatGPT reads it now as :

These values represent the estimated lifespan of the eMMC's different types of memory cells (Type A and Type B). They are usually given in hexadecimal format, where:

* `0x01` indicates that the device is in its first lifespan segment. In general, this means the eMMC is in good condition and has not yet reached a significant amount of its write cycle limit.
* As these values increase (e.g., `0x02`, `0x03`, and so on), it indicates that the eMMC has reached further stages of its lifespan. Higher values (like `0x0A` or above) might suggest the device is approaching its end of life.

eMMC Pre EOL information (EXT_CSD_PRE_EOL_INFO): 0x01

This value indicates the pre-end-of-life status of the eMMC. Different values suggest how close the eMMC is to its estimated end of life:

    0x01: Normal - The device is in a healthy state and far from its end of life.
    0x02: Warning - The device is starting to approach its end of life; closer monitoring might be required.
    0x03: Urgent - The device is very close to its end of life, and it's advisable to consider replacing it.

So while values of Time estimation seems to be interpreted correctly, now ChatGPT for EXT_CSD_PRE_EOL_INFO says that 0x01 is OKay, while 0x02 and 0x03 indicate serious issue.

2 Likes
4 
$ sudo mmc extcsd read /dev/mmcblk0 | grep 'LIFE\|EOL'
eMMC Life Time Estimation A [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A]: 0x0b
eMMC Life Time Estimation B [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B]: 0x0b
eMMC Pre EOL information [EXT_CSD_PRE_EOL_INFO]: 0x01

My Homey, which is hardly does anything, is showing “a higher value” :grimacing:

Somewhere else I found this:

4.2.5 Life time estimation
It is possible to get an estimation on the health status of the device by checking the parameters
EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A and EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B.
The estimation is given in steps of 10% so a value of 0x01 means that 0% to 10% life time used.

Which would mean 0x0b equals 100 to 110% life time used :joy:

1 Like
5

Can you also show, till you are rooted, what shows you docker container stats together with uptime, eg. min. 1-2 hours uptime ?
Also do you have Experiment - Power user enabled ?

Quite interesting article - Wear Estimation for Devices with eMMC Flash Memory - CNX Software

Btw love this picture…

linuxperm
linuxperm706×469 105 KB

1 Like
6 
CONTAINER ID   NAME                CPU %     MEM USAGE / LIMIT     MEM %     NET I/O   BLOCK I/O        PIDS
4accbd7d571a   homey-pro-homekit   3.54%     90.27MiB / 1.855GiB   4.75%     0B / 0B   50.5MB / 106kB   11
f17cbcb4f634   homey-pro-sandbox   0.00%     12.15MiB / 1.855GiB   0.64%     0B / 0B   11.9MB / 279kB   8
507a7464a5a1   homey-pro           13.50%    889.1MiB / 1.855GiB   46.82%    0B / 0B   180MB / 324MB    321

Uptime 17 minutes :wink:

I’ll update this post later tonight, after it’s been running a couple of hours.

After about 2 hours:

CONTAINER ID   NAME                CPU %     MEM USAGE / LIMIT     MEM %     NET I/O   BLOCK I/O        PIDS
4accbd7d571a   homey-pro-homekit   4.06%     95.85MiB / 1.855GiB   5.05%     0B / 0B   50.5MB / 106kB   11
f17cbcb4f634   homey-pro-sandbox   0.00%     12.15MiB / 1.855GiB   0.64%     0B / 0B   11.9MB / 279kB   8
507a7464a5a1   homey-pro           1.91%     981.1MiB / 1.855GiB   51.66%    0B / 0B   213MB / 2.85GB   321

So not a lot of writes at all (although memory usage of the homey-pro container is growing nicely).

Yes :+1:t2:

1 Like
7

You have Block I/O 2.85GB / writes :wink: In two hours ?

8

Surely those are reads, not writes?

EDIT: Docker documentation seems to suggest it’s “writes / reads”:

“BLOCK I/O: The amount of data the container has written to and read from block devices on the host”

1 Like
9

Surely I’m not expert, but I always verify with Portainer Agent (have Portainer running on my Synology) and those were writes. - actually READs were very low. But it could be that Portainer is wrong as well, in today’s world you never know.

Also I consulted ChatGPT on your data (and I know AI could be wrong, actually often it is :wink: )

The Docker container stats for homey-pro show the I/O writes as part of the “BLOCK I/O” section. For the homey-pro container, the BLOCK I/O is given as 213MB / 2.85GB.

Here, the first number (213MB) represents the total data read from the block device (like a disk), and the second number (2.85GB) represents the total data written to the block device.

So, the homey-pro container has performed approximately 2.85 GB of I/O writes.

But if unsure, try with Portainer or maybe someone can really confirm on that.

10

Yep, I read that just moments ago as well and indeed, it suggest that - but you can always verify also with others tools , except of portainer, I use also HTOP and adding WBYTES columns…

funny while official documentation suggests it’s write/read, all others are using order read/writes :rofl:
But the official docs shall be the most trusted. :face_with_diagonal_mouth:

**BLOCK I/O:** The amount of block I/O (disk I/O) performed by the container, displayed as two values separated by a slash (/). The first value represents the amount of data read, and the second value represents the amount of data written.

``BLOCK I/O helps to identify containers that are writing data and shows the total number of bytes read and written to the container file system. Block I/O stats can give you an idea about issues with data persistence.

etc.

11

I’m now using this to determine the overall amount of data written to the eMMC:

grep 'mmcblk0 ' < /proc/diskstats  | awk '{ print $3, ($10 * 512)/1024/1024, "M" }'

Result:

mmcblk0 4143.41 M

4GB in an hour. TBW for these eMMC’s is 11TB, so it’ll take about 115 days to reach that. Gentlemen, start your backups…

2 Likes
12

I knew you will come up with better approach, thank you for your focus here Robert !

In my case :

mmcblk0 38130.5 M
**up 11 hours, 43 minutes**
13

Well. One of the first Homey Pro 2023 running 24/7 with not many devices but used as a development platform.

$ sudo mmc extcsd read /dev/mmcblk0 | grep 'LIFE\|EOL'
eMMC Life Time Estimation A [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A]: 0x0b
eMMC Life Time Estimation B [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B]: 0x0b
eMMC Pre EOL information [EXT_CSD_PRE_EOL_INFO]: 0x01

------------------ Main ---------------------
3 Users (1 owner, 1 user(s), 1 guest(s))
29 Apps (0 SDKv2, 29 SDKv3, 1 updateable, 0 disabled/crashed)
7 Zones
250 Notifications
4 Variables (1 boolean (yes/no), 1 number, 2 string)
0 Flows (0 broken, 0 disabled)
23 Advanced flows (0 broken, 2 disabled)

----------------- Devices -------------------
0 Z-Wave nodes (0 router, 0 battery, 0 unreachable)
15 Zigbee nodes (0 router, 0 end device)
4 Virtual devices
0 Infrared (database) devices
28 Other devices
47 Total devices

Estimated I/O

$ uptime
08:16:31 up 6 min,  1 user,  load average: 0.09, 0.68, 0.45
$ grep 'mmcblk0 ' < /proc/diskstats  | awk '{ print $3, ($10 * 512)/1024/1024, "M" }'
mmcblk0 922.106 M

So 
922.106 M*10 should be 9.221,06 M?

So around 9GB an hour? But 6min are not enough for estimate it.

$ uptime
08:20:22 up 10 min,  1 user,  load average: 0.06, 0.34, 0.36
$ sudo docker container stats
CONTAINER ID   NAME        CPU %     MEM USAGE / LIMIT    MEM %     NET I/O   BLOCK I/O       PIDS
e70a009cf15d   homey-pro   10.14%    1009MiB / 1.855GiB   53.11%    0B / 0B   205MB / 214MB   330

Will report back later the day when the homey has been running for a while

1 Like
14

The 922MB written is the amount written since the last boot, so almost 1GB in only 6 minutes :grimacing:

Of course it might be a burst of writes directly after a reboot, so it would be worthwhile to check how much was written in, say, 24 hours. That should give a good indication of a “normal” I/O load.

EDIT: although having said that, I just check my HP2023 again:

  • first hour: 4GB written in total
  • second hour: 8GB written in total

So it’s keeping with the 4GB/h average…

1 Like
15

Btw with

fatrace -fW

you can also monitor live what is being written and where.
(needs to be also installed first)

1 Like
16 
$ uptime
 09:06:33 up 60 min,  1 user,  load average: 0.84, 0.62, 0.81
$ grep 'mmcblk0 ' < /proc/diskstats  | awk '{ print $3, ($10 * 512)/1024/1024, "M" }'
mmcblk0 4861.63 M

:person_shrugging:

1 Like
17

FYI: Moved …

1 Like
18

Just small comparison (in my case I even did some small optimisations already :rofl:)

mmcblk0 423208 M
up 3 days, 1 hour, 48 minutes
Docker stats : 181GB

So “just” 5760 MB / hour.

Without that optimisations, I would estimate it to 8GB/hour.

66 Apps / 283 Total devices

19

Where can we place bets on when the first HP2023’s will start failing with flash errors?

My prediction: somewhere around April.

2 Likes
20

I believe it will be fixed till then, for sure :wink: