OpenBSD Journal

tmpfs on its last legs

Contributed by Anonymous Coward on from the big axe dept.

As a result of apparent lack of maintenance, Theo de Raadt has disabled tmpfs.


CVSROOT:	/cvs
Module name:	src
Changes by:	deraadt@cvs.openbsd.org	2016/07/25 13:52:56

Modified files:
	sys/conf       : GENERIC 

Log message:
disable tmpfs because it receives zero maintainance.

(Comments are closed)

Comments

  1. By Anonymous Coward (91.241.33.66) on

    Huh?
    No more building stuff in memory?

    Comments

    1. By rc (160.83.30.200) on

      > Huh?
      > No more building stuff in memory?

      SSD seems fast enough. haven't used it in Ages. That and I wont care if a build takes a day or two these days on my sparc.

    2. By Anonymous Coward (151.61.85.67) on

      > Huh?
      > No more building stuff in memory?

      mount_mfs still works.

      Comments

      1. By Anonymous Coward (91.241.33.66) on

        > > Huh?
        > > No more building stuff in memory?
        >
        > mount_mfs still works.

        Yeah, but mfs looks like inferior tech compared to tmpfs...
        Link: http://undeadly.org/cgi?action=article&sid=20131217081921&pid=4

    3. By Anonymous Coward (173.64.193.222) on

      > Huh?
      > No more building stuff in memory?

      Can't you just re-enable it by uncommenting this line/rebuilding the kernel?

      OpenBSD 6.0 already has errata 1 which requires a kernel rebuild anyway.

    4. By Anonymous Coward (88.64.186.202) on

      > Huh?
      > No more building stuff in memory?
      Buffercache to the rescue! It does a good enough job for me on armv7 with an really slow sd-card. I dont really need tmpfs/mfs for building fast...

    5. By Anonymous Coward (62.235.124.135) on

      > Huh?
      > No more building stuff in memory?

      But does tmpfs just need maintenance?

  2. By Anonymous Coward (12.153.51.253) on

    Does anyone know what maintenance it actually needs?

    This is a shame, since it was nice getting RAM back after deleting files from tmpfs mounts.

    Comments

    1. By Anonymous Coward (92.40.83.93) on

      > This is a shame, since it was nice getting RAM back after deleting files from tmpfs mounts.

      This is an odd reason for liking a file system.

      Comments

      1. By Anonymous Coward (96.229.138.18) on

        > > This is a shame, since it was nice getting RAM back after deleting files from tmpfs mounts.
        >
        > This is an odd reason for liking a file system.

        Yes. It's like liking eating certain food because of how you poop later on.

      2. By Anonymous Coward (109.236.90.209) on

        > > This is a shame, since it was nice getting RAM back after deleting files from tmpfs mounts.
        >
        > This is an odd reason for liking a file system.

        Not really, considering the only other alternative was/is mfs, which is a horrible "just bodge FFS to work entirely in RAM somewhere" solution, and does NOT free up RAM when files are deleted.

        Getting RAM back after deleting files is an excellent reason to use tmpfs instead of mfs.

  3. By Anonymous Coward (50.174.139.17) on

    To those who wish to re-enable TMPFS, reverse this diff.

    To those who question as to why this is necessary, on all flash media, there is a limited number of write (and read, for MLC/TLC) cycles that can be made before the flash chip becomes a tiny brick. This varies depending on the quality of the technology (SLC, MLC or TLC, best to worst). Most cheap (micro)SD cards and USB flash drives fall under the TLC category, whereas most SSDs are fortunate enough to have MLC. SLC is reserved for the far more expensive 'industrial quality' flash media.

    MLC and TLC flash suffers from something called 'read disturb,' which causes data corruption after many reads to a cell. This is usually mitigated by the FTL (Flash Translation Layer), by moving data cells after a certain number of reads.

    I've had quite a few SD cards die on me after compiling some software projects on a Raspberry Pi before coming to this realization.

    Comments

    1. By Anonymous Coward (210.246.20.30) on

      > To those who wish to re-enable TMPFS, reverse
      >
      > To those who question as to why this is necessary, on all flash media, there is a limited number of write (and read, for MLC/TLC) cycles that can be made before the flash chip becomes a tiny brick. This varies depending on the quality of the technology (SLC, MLC or TLC, best to worst). Most cheap (micro)SD cards and USB flash drives fall under the TLC category, whereas most SSDs are fortunate enough to have MLC. SLC is reserved for the far more expensive industrial quality flash media.
      >
      > MLC and TLC flash suffers from something called
      >
      > Ive had quite a few SD cards die on me after compiling some software projects on a Raspberry Pi before coming to this realization.

      Most consumer SSDs seem to be TLC these days. Intel replaced their 530 (MLC) with the 540s (TCL) and most others are going the same way. It would be interesting to compare disk writes between different operating systems with TMPFS enabled for those that support it.

    2. By Anonymous Coward (45.78.10.72) on

      Theo de Raadt explained on openbsd-misc
      > But most important -- it recently demonstrated low quality with a of
      > number unexpected NULL dereferences, bogus assertions, and other memory
      > object mishandling -- and came dangerously close to having a security
      > hole.
      >
      > It is below the standard.

      You don't want a OpenBSD with a lot of vulnerabilities.

Latest Articles

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