Omnia (3.11.20) keeps writing to mmcblk0

I see permanent writes to mmcblk0 for more than 24 hours. I’m running 3.11.20 more or less in default settings with minimal custom settings.

I’m not an expert. Is this something to be worried about (not to damage the MMC disk)? How to investigate? Thank you.

Hello @Kes,

Could you be please more specific what means more or less default settings?
In any case, please don’t hesitate to reach our Technical support department, which is available for you at and please don’t forget to include diagnostics file, which you can generate in Foris.

If you’re still on Turris OS 3.x, you can show disk IO per process in htop (column IO_RATE).

1 Like

My current configuration: Installed Nextcloud, Node-Red. /srv directory on mounted HDD. The rest is standard configuration.

Have sent the diagnostic reports to the support email.

This morning I have received “Couldn’t resolve host” error from the updater. Pkgupdate was run manually afterwards. Completed without errors. Omnia restarted as requested after the update. I do not see any continuous writes to mmcblk0 now.

Could it be caused by hanging updater? How to prevent that? Thank you.

running this on router should help you find what’s been changed recently:

find / -xdev -mtime -1

or probably:

find / -xdev -mtime -1|xargs ls -ltrd

I observe the same behavior again: continuous writes to mmcblk0 via LuCI stats from Sunday 2am. But there are no IO operations shown in htop. Is it possible that the LuCI Disk Usage graph shows writes incorrectly and can be ignored? System Load and CPU is increased as well. I do not see anything suspicions via htop and no scheduled task in cron on Sunday 2am. Thanks for any tip.

Found out that the continuous writes are caused by btrfs-transacti
But not able to deal with that more with my level of knowledge
Any suggestions welcome.

Can you make a few snapshots with schnapps and compare them with schnapps cmp? That should point to the changed files.

Well, I have created several snapshots during 10 minutes interval. There are no differences found via schnapps cmp and btrfs-transacti keeps writing. Btw - isn’t it some defragmentation process? Would it cause any difference between the snapshots?

isn’t the root filesystem mounted eith the “noatime” option?

unfortunately “find” builtin into busybox doesn’t have “-mmin” option, maybe findutils can be installed?

I can’t check either now, but

find / -mmin -10
find / -cmin -10

could find out if anything was changed.

There’s a good chance btrfs-transacti is busy handling some background task such as auto-defragmentation. In that case there wouldn’t be any changes to file metadata.

correst, although on my omnia btrfs is mounted with option ssd that should prevent it:

/dev/mmcblk0p1 / btrfs rw,noatime,ssd,space_cache,commit=5,subvolid=303,subvol=/@ 0 0

if that’s true, btrfs-transacti should appear in htop output.
at least sometimes.

unfortunatelly it seems that htop in TOS doesn’t support (or have permissions) to show IO operations. I was able to show them on my other linux system.

seems findutils can be installed and this should work then.

For the kernel configs enabling htop to show IO operations, see Where are iftop, iotop, nethogs and friends? and . It’s not there yet for Turris OS 5.x. But in 3.x, it worked for me.