Thanks, it works!
root@TOjp:~# smartctl -H /dev/sda
smartctl 7.2 2020-12-30 r5155 [armv7l-linux-5.15.127] (localbuild)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
I used an SSD from the very beginning (ordered it along with the Omnia), so /srv was always on the SSD. Is it still recommended to move everything to the SSD and boot from it? Or will I be fine with that setup?
root@omnia:~# mmc extcsd read /dev/mmcblk0 | grep EXT_CSD_DEVICE_LIFE_TIME_EST_TYP
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]: 0x00
The SSD:
sda 8:0 1 119.2G 0 disk /srv
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 10685 -
That depends on what usage you have on other parts of the filesystem. If you’re sure nothing does periodic writes to the internal memory, it should last pretty long. But as soon as your ssd will fail and unmount (and it will happen), the router will happily provide the /srv folder on the internal memory and then the decay can be pretty fast.
My suggestion is: make sure you won’t lose anything irreplaceable when the internal memory dies, have a serial cable ready, and use the internal memory as long as it lives. By moving your system to SSD, you’ll lose the physical-button rollback feature, and that was something I really miss now.
If you want to be on a bit safer side, I suggest adding a script to cron that would periodically check if srv is on the mounted drive, and if not, remount it readonly and shout loudly on you.
@miska that sounds like a decent option to include in reforis? Maybe even have it send a notification email if these are configured?
I checked my internal memory just because I read this topic.
My Omnia is from 2017 and I never gave attention to this. I don’t use applications that need storage. The only data that is written regularly are schnapps snapshots.
My eMMC status is this:
mmc extcsd read /dev/mmcblk0 | egrep 'LIFE|EOL'
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]: 0x07
eMMC Pre EOL information [EXT_CSD_PRE_EOL_INFO]: 0x01
Found this command here: https://netmodule-linux.readthedocs.io/en/latest/howto/mmc.html#health-status
Means my internal MMC will be done quit soon and my Omni is broken then? Why is type A and B so different?
I do not have a serial cable and spare mSATA at the moment. Should I oder this soon?
So, your eMMC has used SLC blocks for 10% of their lifetime and MLC blocks for 70% of their lifetime. The EOL info says Normal (under 80% usage).
Higher usage of MLC blocks makes sense, as they are the Multi-level cells, i.e. 2 or 3 bits stored in one “physical bit”. So there’s 2-3 times higher probability each cell will be touched when writing the same amount of data than with SLC cells.
My suggestion would be to start looking for a serial cable and mSATA drive when the EOL status goes to Warning. However, there’s nothing preventing you ordering these two right now. It might be easier now than later (at least regarding the mSATA drive). You will very probably need them in a few months or years.
Thank you @peci1 for explanation.
Even if I understand little about how Multi-level cells are working…
Checked my favored online electronic parts dealer for the needed pieces and will order them. Just in case.
You forgot that all logs (there could be many of them) are written to eMMC as well, if not redirected 
Indeed. Have a look at /var/log/messages. This is continuously written to and rotated on the eMMC. It will be automatically moved to an installed SSD.
Not automatically - you have to set it either manually or in reForis
All logging on my Omnia is default. No custom settings are made.
-rw------- 1 root root 632.4K Sep 7 20:00 messages
-rw------- 1 root root 1.0M Sep 5 23:12 messages.1
-rw------- 1 root root 21.4K Sep 3 00:12 messages.2.gz
-rw------- 1 root root 54.2K Sep 1 13:12 messages.3.gz
-rw------- 1 root root 14.8K Aug 27 00:12 messages.4.gz
I would say, this files alone cannot bring the eMMC to an end. Maybe there is to add the DNS resolver cache, because I disabled the “use forwarding”. And schnapps writes data every week.
As mentioned in this topic eMMC - live span, health monitoring - #9 by cynerd
Flash memory in TO is (up to my knowledge) SK hynix eMMC4.5 which manufacturer specifies, for density of 4GB, 2.4TB total bytes written before EOL.
I don’t know when or what could write that much data. Let’s even say 1TB in 6 years.
What I said before. I use this Omnia without extra packages.
That’s why I don’t added an extra mSATA card in it.
That’s not right. By default, /var is symlinked to /tmp, which is by default kept only in RAM. The only persistent folder where some data may be written periodically, is /srv. And by default, no apps write here (not sure about the resolver, though). By default, you even lose DHCP lease assignments by rebooting.
Resolver only writes to tmpfs.
/srv I never used and yes after reboot all the log data is gone. So must be in the RAM only.
Then I don’t unterstand from what the eMMC dies.
Or can it just because of the age/runtime of the device?
Of you don’t use “server-software”, then the only activities degrading your eMMC are system upgrades and usage of schnapps.
Then, that must probably be the cause for downgrading my eMMC over the years.
What I don’t understand - my wear out-level is 10-20% with two Indiegogo-TOs, that are running round the clock and have been updated with ~90% of all the upgrades that were handed out until now.
So either I have very good flash or yours is part of a bad batch… 
eMMC could be worn out by leaving all logs etc writing to it. One should redirect logs etc to USB or SSD
Never did that in my environment. And if I remember correctly those logs all write to /tmp, which means RAM, since 2 or 3 years by now.
There might be for sure nonstandard apps installed, that behave differently and thus harm the eMMC.
Search for eMMC on Forum…