OpenBSD Journal

tmpfs Enabled in -current

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)


Comments
  1. By sneaker (sneaker) sneaker@noahpugsley.net on

    How is this different than mfs? Elastic file system size?

    Whatever the function/reason, thanks!

    Comments
    1. By BSDer (24.222.132.42) on

      > How is this different than mfs? Elastic file system size?
      >
      > Whatever the function/reason, thanks!

      I'm glad somebody asked ... I didn't want to have to admit to ignorance :)

    2. By Blake (2a01:e34:ec06:8f90:cabc:c8ff:fedb:4d83) undeadly@2112.net on 2112.net

      > How is this different than mfs? Elastic file system size?

      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
      1. By Blake (2a01:e34:ec06:8f90:cabc:c8ff:fedb:4d83) undeadly@2112.net on 2112.net

        > If somebody has a wikipedia account there's some updating to do:
        >
        > 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

    3. By Marc Espie (espie) on

      > How is this different than mfs? Elastic file system size?
      >
      > 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
      1. By sneaker (sneaker) on

        > > How is this different than mfs? Elastic file system size?
        > >
        > > 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!

      2. By Mycroft Jones (174.1.134.204) david@reactor-core.org on

        > 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...

        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
        1. By Marc Espie (espie) on

          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

          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
          1. By Mycroft Jones (174.1.134.204) david@reactor-core.org on

            > 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...

            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
            1. By Ted Bullock (64.141.41.146) tbullock@northernartifex.com on

              > 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.

              Yes please.

  2. By Anonymous Coward (188.252.255.169) on

    What would be some obvious candidates to put in tmpfs? I've already put /tmp and $HOME/.cache into it...

    /var/run maybe? /var/cache also? Any others? Talking about OpenBSD specific things mainly, not things from ports etc...

    Comments
    1. By S Senator (208.64.77.236) undeadly@senator.net on

      > What would be some obvious candidates to put in tmpfs? I've already put /tmp and $HOME/.cache into it...
      >
      > /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.)

    2. By Janne Johansson (jj) on http://www.inet6.se

      > What would be some obvious candidates to put in tmpfs? I've already put /tmp and $HOME/.cache into it...
      >
      > /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.

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]