Increase default /tmp RAM disk size?

[pLu]

I spotted this in dmesg after updating to 2.3.r.20160406.1411_1 :

ovpns1: link state changed to DOWN
ovpns1: link state changed to UP
pid 92956 (pkg), uid 0 inumber 32 on /tmp: filesystem full
pid 94791 (pkg), uid 0 inumber 31 on /tmp: filesystem full
re2: link state changed to DOWN

I'm using the default 40MiB /tmp RAM disk size.

[MikeV7896]

I believe the setting for this is in one of the System > Advanced pages… I think it might be under Miscellaneous, but I don't remember for certain at the moment.

[pLu]

I know of the setting but the question is if default (minimum recommended) size has to be increased for 2.3.

[jimp]

The minimum sizes have to be what they are for older/smaller NanoBSD platforms like ALIX, eventually they can be increased once we completely stop caring about them (ALIX is EOL… so it won't be long now :-) or when we drop NanoBSD.

[divsys]

….or when we drop NanoBSD

Is dropping NanoBSD in the future gameplan?
Not trying to fan any flames here, just asking if there's a longer term plan to get away from NanoBSD or perhaps to get away from embedded/CF/SD type installs in the future?

Perhaps the thought is SSD & future tech makes such type installs rather superfluous (I'd personally lean that way)?

No predictions or assumptions here, just guessin'  ???

[jimp]

We've hinted at it (and I think mentioned it outright at least once) but yes, NanoBSD will be on the way out. It was good at the time, but the limitations it imposes are really not needed these days. The added complexity of dealing with its wasted space, extra partitions, ro/rw switch timing, etc, are all things we'd be better off without. SSD prices are down, and quality is vastly increased, and worrying about writes is not something many people have to do these days.

Plus a full install with /var and /tmp in RAM would not have that many more writes than NanoBSD (for the base system anyhow…)