Enlarge the littlefs partition — index.html is close to filling it

[Variour]

Problem

partitions.csv reserves only 0x50000 (320 KB, minus LittleFS overhead) for the littlefs partition:

littlefs, data, spiffs,  0x3B0000, 0x50000,

data/index.html alone is currently 234 KB and has grown steadily over recent commits (~218 KB → 234 KB). The upload pipeline (scripts/pre_uploadfs.py) also generates a gzip sibling, index.html.gz (~56 KB), which is legitimately needed alongside the raw file — WebServer.h reads /index.html directly for SPA route fallbacks, while serveStatic uses the .gz sibling for bandwidth savings on normal requests. So index.html + index.html.gz alone already sit around 290 KB, before data/sc/*.json, wifi.json, and wifi.json.gz are added.

This already caused a lfs_write error(-28): File system is full. build failure once, triggered by a related bug where pre_uploadfs.py left stale .gz files in data/ across builds (fixed in commit 1ab7999). Even with that fix, the remaining headroom is only ~30 KB, and any further growth of index.html will overflow the partition again.

Proposed fix

Increase the littlefs partition size in partitions.csv, most likely by shrinking app0/app1 (currently 0x1D0000 / ~1.85 MB each for OTA dual-bank). Needs to be sized against actual current firmware binary size to make sure OTA still has enough room in both app slots.

Open questions

• How much slack do the current app0/app1 firmware binaries have before this becomes a real constraint?
• Should we also revisit whether the raw index.html needs to ship on top of index.html.gz, to reduce pressure independent of partition size?

[bennotk]

Refreshed numbers, plus a correction to one premise in the description.

index.html has grown

315,842 B today, against the 234 KB quoted above. Gzipped it is 75,584 B.

The raw file is not needed on the device

The description assumes index.html and index.html.gz both have to ship, because WebServer.h reads /index.html directly for the SPA route fallbacks. That is not how it behaves: AsyncFileResponse and serveStatic both fall back to a .gz sibling when the raw file is absent, and the shipped firmware has been running that way for a while — the Gzip web assets step in firmware.yml deleted the raw file before buildfs, so released littlefs.bin images have only ever contained index.html.gz.

So the open question "should we revisit whether the raw index.html needs to ship" answers itself: it does not, for anything the web server hands out. Files read through a plain LittleFS.open() are a different matter — Config::loadWifi() opens /wifi.json with no fallback, so .json must stay uncompressed.

The two pipelines disagreed

Path	Behavior	Bytes for the image
CI / OTA (firmware.yml)	gzip, then rm the raw file	97,533
Local (scripts/pre_uploadfs.py)	gzip, keep both	421,378

Against a 327,680 B partition the local path has been over budget for some time — pio run -t uploadfs could not have succeeded, while OTA was never close to the limit. The lfs_write error(-28) quoted above fits that: it is the local path failing, not the released image.

Fixed on claude/favicon-setup-c9ey12: the image is packed from a staging copy under $BUILD_DIR, so both targets produce the same result and the working tree keeps its sources. The duplicate workflow step is gone. Occupancy is now 97,533 B of 327,680 B — 29.8 %, including the favicon from #470.

Slack in the app slots

The remaining open question was how much room app0/app1 have. From the last main build of esp32dev:

Flash: [========  ]  78.7% (used 1495301 bytes from 1900544 bytes)

405,243 B free per slot. Shrinking both to 0x1A0000 puts the firmware at 87.8 % and frees 393,216 B:

app0,     app,  ota_0,   0x10000,  0x1A0000,
app1,     app,  ota_1,   0x1B0000, 0x1A0000,
littlefs, data, spiffs,  0x350000, 0xB0000,    # 720 KB

The catch is deployment: the partition table lives at 0x8000 and OTA does not rewrite it. Devices in the field keep the old layout until each one is re-flashed over USB.

Suggested next step

With the pipelines aligned, the partition is at 29.8 % and growing only with the gzipped UI. Enlarging it looks premature. Worth noting that #464 justifies a separate editor bundle by citing this issue's headroom — that reasoning rests on the outdated figures and is worth revisiting.

---

Generated by Claude Code