/tmp to NAS

Shamefully it hasn’t worked doing that for for TMP as some of the files it won’t create which are needed.

If this is Pi related some have moved to SSD instead of the more fragile SD cards.

They said /tmp not swap. 2 totally different things.

Yes I agree they are 2 different things, although I thought I would try again. I may just buy an adaptor for SATA to USB as I have loads spare SSD.

Yes I did. Don’t. It creates more problems than to stay local. Don’t make yourself dependent on yet another box. BOTH have to work for your Smart Home to work.
Btw. your post makes us victims to the XY problem. So why do you want to do this ?

1 Like

Generally, both boxes are very stable, and I did know that would make it more dependant. Overall RAM is an issue and I am not wanting to drop in a Pi4 yet. I have spare SSD and I have ordered a SATA to USB adaptor now. As such I will copy the SD card to SSD and roll out the now swap and tmpfs and leave it back to normal disk. That way the ware levels won’t be an issue.

Thanks for everyone’s input but seems Pi on a busy system SSD only way to go.

Sorry I thought my post was clear as to why I have /tmp on tmpfs and now why I was trying to move it.

No, and to be frank you still have not answered what the problem is you’re trying to solve.
Is it SD wearout ? Or is it lack of RAM ? Or still something else ?
What HW do we talk about and what applications to use that much ? 1G is enough unless you’re doing anything extraordinary.

You’re still stuck in XY IMHO. Please take care of
How to ask a good question / Help Us Help You - Tutorials & Examples - openHAB Community
in the future.

Definitely not at all. openHABian has ZRAM for the purpose of mitigating SD wearout.
Simple, cheap and standard.

1 Like

Again, why? tmpfs is in RAM, not the SD Card.


Try again. What is your ultimate goal? What results are you trying to achieve? You may not have chosen optimal solutions.

When I first installed openhabian V2.2 there were recommendations to put /tmp on tmpfs and yes I know that is RAM to easy writes on the SD Card. However I starting to run low on RAM and due to the SD Card write cycles I though there was little else but to go back to SD Card or NFS.

So apart from explaining based on recommendation to move to tmpfs I thought my first post was clear about what I wanted to move and why.

Now if your saying that post to move to TMPFS is wrong and that SD Card writes are not longer an issue then I can reverse those changes out.

OK, now we have a picture of the situation you are trying to improve. Thank you.

Others are more experienced with Pi issues than I. My big experience is more UNIX / Linux related.

No problem, I have read my original post multiple times and in my head I thought I explained in enough detail but obviously not.

To further expand the issue with /tmp of tmpfs is that updates download to /tmp. On a 1GB RAM system there is just not enough room so updates fail.

In terms of the writes yes ZRAM is a significant change however I am not in the know enough to say if it was there when I deployed. Looking at the post date I would suggest not.

So Markus is it now that ZRAM can be used there is no more ware issues?

There were no separate recommendations I know of. Btw you confuse openHABian with openHAB. There’s no such thing as openHABian 2.2. And if you meant to say “by the time openHAB 2.2 was current” then that’s 2+ yrs old so no matter what it was I would no longer consider that a valid statement.

OS updates do not download to /tmp. There’s almost nothing in openHABian that would cause downloads (unless you sit in front of the Pi console which you shouldn’t be doing) so I can’t follow you there. Those few occasions that do are far away from filling standard /tmp which is 100MB.

Yes, read the link. I’m just about to make it the default for new installations.

1 Like

Ok I will install ZRAM and change it.

I was doing updates via the openhabian-config to do system updates and it downloaded java to /tmp. This is what made me review the tmpfs situation.

Yeah but even Java (the probably largest among downloads) isn’t THAT huge. Your problem probably was you were using /tmp for other stuff not to belong there (logs, presumably).

It needed about 80MB by the time it downloaded and wanted to decompress. With what I was running it just was to much space needed.

Logs can be a real problem on Linux systems if not periodically purged. Some usually live under /var/log/

Log are always a problem but also a god send when you need them.

So I have installed ZRAM with the default config. So to save any confusion of where this config now is:

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        15G  3.2G   11G  23% /
devtmpfs        484M     0  484M   0% /dev
tmpfs           488M     0  488M   0% /dev/shm
tmpfs           488M  6.6M  482M   2% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           488M     0  488M   0% /sys/fs/cgroup
overlay1        575M  2.7M  530M   1% /var/lib/openhab2
tmpfs           100M  248K  100M   1% /tmp
/dev/mmcblk0p1   42M   23M   19M  55% /boot
/dev/zram1      575M  2.7M  530M   1% /opt/zram/zram1
/dev/zram2      469M   18M  416M   5% /opt/zram/zram2
overlay2        469M   18M  416M   5% /var/log
tmpfs            98M     0   98M   0% /run/user/1000


proc            /proc           proc    defaults          0       0
PARTUUID=529e9566-01  /boot           vfat    defaults          0       2
PARTUUID=529e9566-02  /               ext4    defaults,noatime  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that
      tmpfs           /tmp        tmpfs   nosuid,nodev,size=100m        0       0
#     tmpfs           /var/log/openhab2        tmpfs   nosuid,nodev     0       0
#     tmpfs           /var/tmp        tmpfs   nosuid,nodev              0       0

/usr/share/openhab2          /srv/openhab2-sys           none bind 0 0
/etc/openhab2                /srv/openhab2-conf          none bind 0 0
/var/lib/openhab2            /srv/openhab2-userdata      none bind 0 0
/var/log/openhab2            /srv/openhab2-logs          none bind 0 0
/usr/share/openhab2/addons   /srv/openhab2-addons        none bind 0 0


# swap  alg     mem_limit       disk_size       swap_priority   page-cluster    swappiness
swap    lz4     200M            600M            75              0               90

# dir   alg     mem_limit       disk_size       target_dir              bind_dir
dir     lz4     200M            600M            /var/lib/openhab2       /openhab2.bind

# log   alg     mem_limit       disk_size       target_dir              bind_dir                oldlog_dir
log     lzo     150M            500M            /var/log                /log.bind


It didn’t ring a bell right away but now I know why I was irritated … just checked, latest Raspbian/openHABian does not mount /tmp at all.
There’s not much writing to /tmp really so no big time reason to make that a ramfs/tmpfs/zram/whatever.

Did you actually install that manually or why is it 100MB on your system ?
So if you simply unmount that you will have all the space of /

On ZRAM, there’s an upcoming change to replace

dir     lz4     200M            600M            /var/lib/openhab2       /openhab2.bind


dir     lz4     150M            500M            /var/lib/openhab2/persistence   /persistence.bind

… you can edit that manually, reboot to activate.

You can also expriment with adding a ztab line for /tmp if you want.

The /tmp was on the guide I followed 2 years ago. To be honest I can’t remember what tmp had lots of writes as in /var/tmp /tmp which is why I implemented it. I had blue tooth scanning on and it was smashing the SD Card back then hence putting a load into tmpfs.

The 100MB limit was something I put on today.