with emmc unmounted

sudo e2fsck -f /dev/mmcblk1p1 # check filesystem
sudo resize2fs -M /dev/mmcblk1p1 # shrink filesystem to minimum size
sudo fdisk /dev/mmcblk1 # shrink partition
sudo resize2fs /dev/mmcblk1p1 # Expand filesystem to fill the new (smaller) partition

execute the following commands:

p – print table (to get start sector of p1)
d – delete partition (I know this is scary but it will be OK)
n – create new primary partition #1
  - Use same start sector
  - Choose a smaller size that is slightly larger than the new filesystem
  - when asked "Partition #1 contains a ext4 signature. Do you want to remove the signature?" answer No
w – write changes

• Start sector was: 8192
• New end sector: something corresponding to ~5.2GB:
  • 1 GiB = 1,073,741,824 bytes
  • 5.2 × 1,073,741,824 = 5,583,457,484.8 bytes
  • 5,583,457,485 / 512 ≈ 10,910,860 sectors
  • end = 8192 + 10,910,860 - 1 = 10,919,051

so that:

• temporary files created by programs go to RAM
• keeps logs/temp writes from wearing out eMMC
• mode=1777: world-writable sticky bit (normal for /tmp)
• limit size of files/logs

inside /etc/fstab

tmpfs /tmp      tmpfs defaults,noatime,mode=1777,size=128M 0 0
tmpfs /var/tmp  tmpfs defaults,noatime,mode=1777,size=64M  0 0
tmpfs /var/log  tmpfs defaults,noatime,mode=0755,size=32M  0 0

• you'll have no logs for boot failures
• inside /etc/systemd/journald.conf

Storage=volatile
RuntimeMaxUse=10M
RuntimeKeepFree=2M
SystemMaxUse=0   # ignored in volatile mode

not sure data=writeback especially is a good idea and will survive ungraceful powerdown ongoingly without then mounting as RO on reboot at some point due to corrupted system. I'm thinking though even though data corruption is more likely, it will not flag a disk corruption. Instead some file data may be lost.

• in /etc/fstab: /dev/mmcblk1p1 / ext4 noatime,data=writeback,barrier=1,commit=60,errors=remount-ro 0 1
  • noatime: don't update access time every time you read a file
  • data=writeback: lighter journaling (metadata-only)
  • commit=60: group writes once per minute instead of 5 seconds
  • barrier=1: maintain safety
  • data=writeback + sudden power loss = some recently changed files may become garbage inside (but no FS corruption)
• add/change the cmdline in uEnv.txt (otherwise data=writeback will cause kernel to remount partition as Read Only):
  • cmdline=coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 root=/dev/mmcblk1p1 rw rootfstype=ext4 rootwait

• When a file is deleted trim says to tell the OS to tell the flash controller that those blocks are no longer used.
• Unused blocks even in the file system can be used by the controller to help with wear leveling
• Continuous trim is apparently a bad idea but for wear leveling a periodic trim of 1x/week is helpful

sudo systemctl enable fstrim.timer # defaults to 1x/week
sudo systemctl start fstrim.timer

• Zram doesn't help wear leveling directly but helps to maximize RAM availability so it can be helpful if that's an issue:

the below suggestions have not been tested

sudo apt update
sudo apt install zram-tools # or sudo apt install systemd-zram-generator
sudo nano /etc/systemd/zram-generator.conf

inside /etc/systemd/zram-generator.conf

# ===========================
# ZRAM configuration for BBB
# ===========================

[zram0]
# swap zram
type = swap
compression-algorithm = zstd
zram-size = 256M

[zram1]
# /var/log on zram
type = ext4
mount-point = /var/log
zram-size = 64M

[zram2]
# /tmp on zram (optional)
type = ext4
mount-point = /tmp
zram-size = 64M

then

sudo systemctl daemon-reload
sudo systemctl start /dev/zram0 # check if already started
sudo systemctl start /dev/zram1
sudo systemctl start /dev/zram2
# check
lsblk
zramctl
df -h
# disable journaling
tune2fs -O ^has_journal /dev/zram1 # do not do for zram0 Yes do for zram2
mkswap /dev/zram0

If using zram, remove the /tmp and /var/log lines in /etc/fstab or they will override zram mounts.