Writing to mmcblk0p1 concerns

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.

2 Likes

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.

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

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.

1 Like

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

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

Following this:
https://gitlab.labs.nic.cz/turris/openwrt/issues/266

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.

Beware


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.

This one Rescue modes when booting from external drive? - SW help - Turris forum?

1 Like

Yes, thank you. That would be what Iā€™m concerned about.

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 ?

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 SysadminGuide - btrfs Wiki


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

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.

1 Like

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.

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

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?

Yes, I expect it will eventually get backported ā€“ but I donā€™t think you need to worry about these kresd writes.