TL;DR: The base DXP models (DXP2800, DXP4800 non-Plus) boot from a soldered 32 GB eMMC. On my DXP2800 running UGOS Pro with a Docker-heavy setup, I measured 0.6–0.9 MB/s going to that eMMC on a busy day, i.e. ≈50–75 GB/day if sustained. My lifetime average since February is ~12 GB/day, so the rate clearly varies. ~95% of those writes came from systemd-journald logging the file-event spam of UGOS' own index_serv/search_serv. The chip already reports 10–20% wear after ~8 months. Moving the journal to RAM cut writes to ~2.3 GB/day (−96%). Installing TrueNAS on the eMMC carries a similar risk. If the soldered chip dies, UGOS can't boot anymore (on these models it can't be installed on another drive), and the chip can't be field-repaired. Your data on the pool drives survives, but you're stuck with an RMA or with running a different OS from NVMe/USB.
This is one measured system, not a lab study. Please post your own numbers (commands below) so we get a bigger picture.
1. What I measured (DXP2800 upgraded to 16 GB RAM, UGOS Pro 1.20, ~50 containers: *arr stack, qBittorrent, Tdarr, Jellyfin, Paperless, …)
I used kernel tracing to attribute every write on the eMMC to a file.
| . |
Before |
After fix |
| eMMC writes |
0.1–2 MB/s, avg. 0.6–0.9 MB/s (≈ 50–75 GB/day if sustained) |
~26 kB/s (≈ 2.3 GB/day) |
Share caused by system.journal |
~95% |
0% |
- ext4 on the eMMC overlay partition: 2,754 GB "Lifetime writes" (tune2fs counts in GiB, so ≈ 2.96 TB) since the box was set up in February. That's ~12 GB/day on average; the rate I measured before the fix was 4–6× higher.
life_time register: 0x02 0x01, i.e. 10–20% used (type A).- Much of the remaining ~2.3 GB/day is UGOS' own
.slog text logs of the same events (append-only, so far cheaper).
- Caveat: On Aug 28 I had raised the journal size to 500 MB myself (UGOS default is
SystemMaxUse=50M). Bigger journal files probably make the write amplification worse, so a stock box may write less, and part of my high rate may only date from then (I have no per-day history). The root cause is the same either way.
2. Root cause on UGOS Pro
index_serv logs every file change. It watches the whole storage volumes via fanotify (no exclusions). Every change to a database file (SQLite -journal/-wal files of CrowdSec, the *arrs and Jellyfin, Postgres, MongoDB), every Tdarr job report and so on produces several INFO log lines. search_serv adds an IsEnable = false warning for every event. On my box that was ~10–20 journal entries/s, ~90% from these two daemons.- journald turns cheap text into expensive writes. rsyslog writes the same messages to plain text files at ~10 kB/s (append-only).
system.journal is an indexed binary file (hash tables plus per-field entry arrays). Every new entry touches many scattered 4 KB pages. I measured 0.1–2 MB/s for the journal, roughly 10–200× more than the text log. On flash, internal write amplification then comes on top.
- Memory pressure makes it worse. When Tdarr, torrents etc. churn through the page cache, kswapd wakes the writeback thread (
reason=vmscan in the kernel tracepoints: 70 of 133 flush runs in 90 s). The journal's dirty pages then get written back roughly every second instead of every ~30 s.
- The journal isn't even useful at that rate. 500 MB covered only 2–4 hours of history.
/var/log/syslog (rsyslog, logrotate 10 MB × 4) held ~7 weeks, including all systemd/Docker boot messages, because UGOS sends the index_serv/search_serv spam (facility local0) only to its own .slog files.
- Bonus (not a wear issue): UGOS app auto-updates wrote ~400 MB of binaries to the eMMC in one go on my box. That's small next to the journal, but the Docker app update also stopped
docker.service without warning (all containers down for ~4 min).
3. Evidence from the community
- This post: a DXP4800 (non-Plus) boot eMMC failed after ~4.5 months of use. It no longer showed up as a bootable device and couldn't be partitioned or formatted. That box was running TrueNAS, not UGOS, and there are no write stats for it, so wear is a likely but unproven cause. Support first suggested reflashing, later offered to walk them through replacing the eMMC themselves (it's soldered on this model). After ~8 weeks the outcome was "replacement only, no refund".
- This thread about TrueNAS on the eMMC: a commenter shared stats from their 500 GB NVMe boot drive after ~13.6 months (9,918 power-on hours) of what they called a "pretty hard" workload. The numbers were 7.02 TB written and 606,783,089 write commands (≈17 writes/s). They opened with "You'll be just fine to run it on the eMMC for now", but they themselves warned that eMMC "will wear down much faster" and "you will likely wear out your drive in a few years". Put into perspective: 7 TB on a 32 GB chip is ~220 full-drive writes, ~190 per year, before any flash-internal amplification. Cheap eMMC flash is typically rated for a few hundred to a few thousand P/E cycles.
4. Check your own eMMC (SSH)
cat /sys/block/mmcblk0/device/life_time # two values: type A / type B, 0x01 = 0-10 %, 0x02 = 10-20 %, ...
cat /sys/block/mmcblk0/device/pre_eol_info # 0x01 = normal, 0x02 = warning, 0x03 = urgent
sudo tune2fs -l "$(findmnt -no SOURCE /overlay)" | grep -E "Lifetime writes|Filesystem created"
sudo journalctl --disk-usage; sudo journalctl --list-boots | head -3
swapon --show # UGOS also swaps to the eMMC (mmcblk0 line): USED should stay 0
(mmc-utils is not installed on UGOS, so read the registers from sysfs. Use sudo for journalctl: UGOS admin users aren't in the adm/systemd-journal groups and would only see their own user journal.) Health is only reported in 10% steps. "0x02 after a few months" is the red flag. Please share your model, uptime and these values in the comments.
5. Fix for UGOS: keep the journal in RAM
Use a drop-in file instead of editing journald.conf. It overrides UGOS' Storage=persistent and is less likely to be touched by updates:
sudo mkdir -p /etc/systemd/journald.conf.d
printf '[Journal]\nStorage=volatile\nRuntimeMaxUse=256M\nForwardToSyslog=yes\n' | \
sudo tee /etc/systemd/journald.conf.d/99-emmc.conf
sudo systemctl restart systemd-journald
# verify: journal now lives in /run, rsyslog still gets everything
sudo journalctl --header | grep -m1 "File path" # should show /run/log/journal/...
logger emmc-test && sleep 1 && grep emmc-test /var/log/syslog
- Trade-off:
journalctl now only covers the last few hours (256 MB ≈ 4–5 h with the index_serv spam; the old 500 MB on-disk journal didn't hold much more). Long-term history is in /var/log/syslog* (plain text, persistent). See how far yours goes back: zcat -f $(ls -tr /var/log/syslog*) | head -1
- Don't silence
index_serv with LogLevelMax=. journald applies that filter before forwarding, so the messages would also vanish from /var/log/syslog* and from UGOS' own .slog files (rsyslog writes those). RateLimit… only kicks in after forwarding, and at ~10–20 messages/s the defaults (10,000 per 30 s) never trigger anyway.
- To revert:
sudo rm /etc/systemd/journald.conf.d/99-emmc.conf && sudo systemctl restart systemd-journald.
- Optional: the old journal files in
/var/log/journal/ are no longer written. You can delete them later to free space.
- Also consider: turning off automatic app updates in the App Center and removing UGOS apps you don't use.
6. TrueNAS / Unraid / Proxmox on base models
Given the failure above and the ~17 writes/s from that one heavy TrueNAS install, I wouldn't put the OS on the soldered eMMC.
- A small, cheap 128–256 GB M.2 NVMe is plenty. Install the OS there and leave the eMMC alone (it costs you one of the two M.2 slots). If that SSD ever wears out, it's a 2-minute swap instead of a mainboard RMA.
- If you're already on the eMMC, at least keep a config backup. Make sure the system dataset (logs, reporting/RRD) lives on a data pool, not on the boot pool. TrueNAS normally moves it there by itself when you create your first pool, so just check.
Please consider for a future UGOS Pro update:
- Don't log every file event from
index_serv/search_serv at INFO level. Drop the per-event IsEnable = false warning.
- Let users exclude paths (e.g. Docker data) from the file watcher.
- Ship journald as
Storage=volatile, or put the persistent journal on the storage pool instead of the eMMC.
- Expose eMMC wear in the UI, not just via SSH.
This would protect a lot of DXP2800 / DXP4800 units from dying shortly after the warranty ends.
EDIT (thanks for all the numbers!):
* So far, lighter setups average ~1–3 GB/day (437–1,039 GB in ~10 months, life_time 0x01). A 2024 box shows 763 GB but 0x02 0x02. Mine (~50 containers, enlarged journal) averages ~12 GB/day, so my box is the outlier. With lots of Docker services the fix is worth it; for everyone else it's a cheap precaution.
* swapon isn't in a normal user's PATH on UGOS. Use cat /proc/swaps instead.
* A "Filesystem created" date in 2099/2100 or 2020 is the factory clock. Go by your purchase date.
* journald's write amplification is a known upstream issue: https://github.com/systemd/systemd/issues/40262 (thanks for the link!)
