Contributed by tbert on from the nothing-lasts-forever dept.
Marc Espie (espie@) committed a change that enables tmpfs in OpenBSD -current:
CVSROOT: /cvs Module name: src Changes by: espie@cvs.openbsd.org 2013/12/14 16:28:02 Modified files: sbin : Makefile sys/conf : GENERIC Log message: enable tmpfs so it gets tested some more. okay kettenis@, martin@, beck@, krw@, tedu@, millert@
Thanks to Pedro Martelletto, who did much of this work.
Like it says on the label, enabled for testing; as always, community effort is vital to ensuring the continuing quality of OpenBSD releases.
(Comments are closed)
By sneaker (sneaker) sneaker@noahpugsley.net on
Whatever the function/reason, thanks!
Comments
By BSDer (24.222.132.42) on
>
> Whatever the function/reason, thanks!
I'm glad somebody asked ... I didn't want to have to admit to ignorance :)
By Blake (2a01:e34:ec06:8f90:cabc:c8ff:fedb:4d83) undeadly@2112.net on 2112.net
from a bit of googling:
"tmpfs is a better MFS, it is faster and can free unused memory"
If somebody has a wikipedia account there's some updating to do:
http://en.wikipedia.org/wiki/Tmpfs
Comments
By Blake (2a01:e34:ec06:8f90:cabc:c8ff:fedb:4d83) undeadly@2112.net on 2112.net
>
> http://en.wikipedia.org/wiki/Tmpfs
Awesome; that didn't take long!
Looks like we have a man page too:
http://www.openbsd.org/cgi-bin/man.cgi?query=mount_tmpfs
By Marc Espie (espie) on
>
> Whatever the function/reason, thanks!
Well, mfs is layered on top of ufs/ffs, so there are all sorts of inefficiencies: the code of mfs tries really hard not to write to disk... which happens to be memory, so as fast as code.
so, tmpfs uses a bit less memory, and is very much faster for some operations (like rm -rf large directories is almost instantaneous, which is great for building stuff in tmpfs).
There are also some fringe cases (quick a/c/mtime modifications) where tmpfs appears to work better.
Also, mfs means you have to set aside some of your memory explicitly for a memory fs, whereas tmpfs is more dynamic, and grows as needed (as long as you have memory/swap, though you can still reserve space).
Another point that *may* be important is that eventually, it may be possible to remove mfs, which is seriously entangled with ufs/ffs, thus making it simpler to improve ffs...
Comments
By sneaker (sneaker) on
> >
> > Whatever the function/reason, thanks!
>
> Well, mfs is layered on top of ufs/ffs, so there are all sorts of inefficiencies: the code of mfs tries really hard not to write to disk... which happens to be memory, so as fast as code.
>
> so, tmpfs uses a bit less memory, and is very much faster for some operations (like rm -rf large directories is almost instantaneous, which is great for building stuff in tmpfs).
>
> There are also some fringe cases (quick a/c/mtime modifications) where tmpfs appears to work better.
>
> Also, mfs means you have to set aside some of your memory explicitly for a memory fs, whereas tmpfs is more dynamic, and grows as needed (as long as you have memory/swap, though you can still reserve space).
>
> Another point that *may* be important is that eventually, it may be possible to remove mfs, which is seriously entangled with ufs/ffs, thus making it simpler to improve ffs...
>
>
A perfect answer, from the guy who committed it no less, and in no time. Thanks Marc! Thanks Pedro!
By Mycroft Jones (174.1.134.204) david@reactor-core.org on
This week I upgraded from OpenBSD 5.0 to 5.4.
I have a Maildir with 30,000 messages in it. Before the upgrade, mutt opened the Maildir in 5 seconds or so. Since the upgrade, mutt has been taking more than 60 seconds. Enabling header caching did not change the opening time one bit.
So, if there are any improvements that need making to ffs, I hope it fixes this! The Maildir is my main INBOX, and I hate moving my mails to archives, I love the quick search feature.
Mycroft
Comments
By Marc Espie (espie) on
>
> So, if there are any improvements that need making to ffs, I hope it fixes this! The Maildir is my main INBOX, and I hate moving my mails to archives, I love the quick search feature.
>
> Mycroft
Yeah, there is a bug somewhere in the disk file system. No-one knows exactly when it got in, no-one has found it, but it's maddening. Maybe it's a driver issue, maybe it's more generic. There is an unexplained slowdown somewhere...
Comments
By Mycroft Jones (174.1.134.204) david@reactor-core.org on
While I look forward to seeing fixes and speedups in the ffs layer, I just fixed the slowdown problem.
Somehow the freeswitch server got re-enabled and was in a continual reboot loop that was sucking up cpu. Now I've properly disabled it and my 30k INBOX is opening in under 5 seconds. The whole system is zippy.
I had the freeswitch port working (except that some phone calls didn't work right) over a year ago. If anyone is interested, I'll revisit it and see if it has matured to where it can be made an official port.
Comments
By Ted Bullock (64.141.41.146) tbullock@northernartifex.com on
Yes please.
By Anonymous Coward (188.252.255.169) on
/var/run maybe? /var/cache also? Any others? Talking about OpenBSD specific things mainly, not things from ports etc...
Comments
By S Senator (208.64.77.236) undeadly@senator.net on
>
> /var/run maybe? /var/cache also? Any others? Talking about OpenBSD specific things mainly, not things from ports etc...
All of /var except for /var/db, for one. /dev too. (Be sure to squirrel away /dev/MAKEDEV into /sbin.) That way / and probably /usr can be mounted read-only. Depending what you have installed, /usr/local/arpwatch or /var/arpwatch (pick your target) are also good candidates.
The goal should be that not only is the system unmodifiable (securelevel, etc), but in an error state you can longjmp back to a known, verified, good baseline config. With / and /usr read-only, and the only modified area in mfs or tmpfs, a production system can be reset by telling the nearest pair of hands and eyes to just powercycle the system. (Agreed, in advance, this is not good for forensic analysis, but it is ideal for a production system under attack. For forensic analysis, the logging goes elsewhere.)
By Janne Johansson (jj) on http://www.inet6.se
>
> /var/run maybe? /var/cache also? Any others? Talking about OpenBSD specific things mainly, not things from ports etc...
I have /usr/obj (and the xobj/pobj dirs if that machine builds x11/ports) in ram, and also /usr/src/sys/arch/amd64/compile as a mfs/tmpfs.
I never ever reboot in the middle of a build and want to restart from that point when compiling system stuff.
Since neither mfs nor tmpfs eat a lot of RAM while unused, it doesn't really hurt to have them there if you don't compile very often.
Since some people want /var/tmp to stick over reboots, perhaps point this to somewhere where you do use mfs/tmpfs:es:
PKG_TMPDIR Temporary area where package information files will be extracted, instead of /var/tmp.