Writing to mmcblk0p1 concerns

[jklaas]

Not really sure where to put this. After reading concerns about wearing out the built in flash, I decided to add the Disks monitor to see how often mmcblk0p1 is written to. I set up the block_dump debugging outlined here and left it on for a little over 10 hours.

I found that a few processes write to the disk.

Kresd writes to it once every 1:20:21 (one hour, 20 minutes and 21 seconds)
btrfs-transaction writes to it much more often, every 30-45 seconds, 2-13 writes each time with 256 sectors
kworker/u4:4 writes to it randomly every 0-30-ish seconds with 8 sectors, 150-270 writes each time.

Does this seem like normal activity?

It does seem like a lot of writes, but I don’t really know. In my past experience with OpenWRT, this sort of thing was dealt with using overlay filesystems on USB drives. Otherwise, I don’t think the flash space was written much at all.

[paja]

Hi,
this situation is probably caused by the older kernel in TOS 3.11.x. In TOS 4.x/5.x this is fixed by commit which is part of 4.14 Kernel

So this should be fixed by upgrading to TOS 4, but just to be sure, I created an issue for this topic.

kernel: emmc and TOS 3x BTRFS writes (#266) · Issues · Turris / openwrt

[ssdnvv]

In TOS 4.x/5.x

Until now I’ve only read about TOS 4.x - so what is 5.x about? Do you have a roadmap somewhere publicly accessible?

[paja]

4.x is based on OpenWrt 18.06, 5.x will be based on OpenWrt 19.0X. I’m not aware of any publicly available roadmap right now.

[ssdnvv]

I’m not aware of any publicly available roadmap right now.

Would be nice to have some sort of ETA - you used to have this in the beginning of this project…

[jklaas]

@paja

this situation is probably caused by the older kernel in TOS 3.11.x. In TOS 4.x/5.x this is fixed by commit which is part of 4.14 Kernel

I’ve since installed 5.0.0 (and 5.0.1) and I’m still concerned about writes to the eMMC partition.

Following this:

kernel: emmc and TOS 3x BTRFS writes (#266) · Issues · Turris / openwrt

I set this up:
echo 1 > /proc/sys/vm/block_dump
and looked at the syslog output which I send to my server elsewhere on my network.

grep "debug kernel" doesn’t seem to yield anything, but looking for WRITE block does still show btrfs still writes to the disk pretty often.

Looking at the wear of my eMMC makes me a little concerned:

mmc extcsd read /dev/mmcblk0 | grep EXT_CSD_DEVICE_LIFE_TIME_EST
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]: 0x02

seems to indicate my eMMC has used up around 20% of it’s reallocation sectors. I realize I’ll have to move to an mSATA disk at some point, and I hope the uboot firmware is updated before then for my older Omnia.

[anon82920800]

@jklaas

seems to indicate my eMMC has used up around 20% of it’s reallocation sectors.

Beware

@cynerd

This is secondary statistics and tells you nothing about complete wear. Common wear is an avalanche effect. Nothing is happening for a long time and then all blocks starts failing at once. Meaning percentage of used reserved blocks might start rising very quickly.

---

@jklaas

I hope the uboot firmware is updated before then for my older Omnia.

What is missing that prevents the deployment of the OS on a SSD?

[jklaas]

@anon82920800

What is missing that prevents the deployment of the OS on a SSD?

From what I read, it’s more about the recovery options, but i could be wrong. I was looking for the issues the other day, but couldn’t find them. It’s not urgent or particularly important at the moment, but I also don’t want to wait until it is. Perhaps that makes it important, but not urgent.

[anon82920800]

@jklaas

From what I read, it’s more about the recovery options, but i could be wrong. I was looking for the issues the other day, but couldn’t find them

This one Rescue modes when booting from external drive??

[jklaas]

Yes, thank you. That would be what I’m concerned about.

[Laurent]

Is it useful or recommended to periodically run a fstrim command on the root ‘/’ btrfs file system (mmcblk0p1) or it can negatively affect the lifetime of the eMMC flash ?

Or maybe, there Is already a “TRIM” cron or timer configured by default in Omia OS ?

[anon82920800]

@Laurent

it can negatively affect the lifetime of the eMMC flash ?

this technical paper https://cosmoss-vt.github.io/pages/pubs/trim-kim-gcce14.pdf claims (if it can be trusted) that it improves eMMC lifetime.

The question though is whether and to which extent it makes sense with BTRFS’s CoW https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Copy_on_Write_.28CoW.29

---

@Laurent

Or maybe, there Is already a “TRIM” cron or timer configured by default in Omia OS ?

crons jobs are defined in /etc/cron.d/

[peci1]

The system MMC partition is mounted with nodatacow option, so CoW only occurs when you first change a file that’s a part of a snapshot.

[anon82920800]

Then TRIM operation should probably not be colliding with the time slot when schnapps cron job is being run though I am not sure whether it could actually cause some issue since it appears to be supported https://btrfs.wiki.kernel.org/index.php/FAQ#Does_Btrfs_support_TRIM.2Fdiscard.3F

That said most TRIM related publications are focussing on SSD and there is not much on the impact/effects on different file systems, let alone on the combination TRIM < eMMC > BTRFS.

[vcunat]

@jklaas

Kresd writes to it once every 1:20:21 (one hour, 20 minutes and 21 seconds)

All writes from kresd should be gone now, on HBT 5.x stable currently: Turris OS 5.0.2 is out!

[Jirka]

its possible to apply it also to 3.x branch? ie. could you please link the fix, maybe it could be backported…?

anyway kworker and transaction worries me even more. I will try to watch writes on my router for a while. Could someone expleains, what this kworker could be?

[vcunat]

Yes, I expect it will eventually get backported – but I don’t think you need to worry about these kresd writes.