Hey, I’ve recently designed a Poster about the FHS since I often forget where I should place or find things. Do you have any feedback how to make it better?

I updated the poster: https://whimsical.com/fhs-L6iL5t8kBtCFzAQywZyP4X use the link to see online.

Dark mode

Old version

  • KISSmyOS@lemmy.world
    link
    fedilink
    arrow-up
    16
    ·
    11 months ago

    Where should I mount my additional internal HDD’s?
    /media doesn’t fit cause they aren’t removable
    /mnt doesn’t fit cause they aren’t mounted temporarily
    Currently I have them mounted as /home/user/data and /home/user/backup.
    Any reason not to do it like this?

    • seaQueue@lemmy.world
      link
      fedilink
      arrow-up
      17
      ·
      edit-2
      11 months ago

      I just mount mine into /mnt and bind mount subdirectories from them into wherever I need the space.

      Edit: if you want a more theoretically correct location according to the FHS you could mount drives somewhere under /run and bind their contents from there. I’ve done that before as well.

    • TheEntity@kbin.social
      link
      fedilink
      arrow-up
      9
      ·
      11 months ago

      If they are internal and permanent (read: unlikely to be removed on a daily basis), I’d just mount them based on their purpose and not them being separate HDDs physically. If they are meant for logs, mount them at /var/log. If they are meant for your movies, /home/user/data is more than fine. In general FHS describes the directory hierarchy, not which parts of it are mountpoints and which are physically on the same media. Technically you’re fine having each and every directory on a separate HDD.

    • Eager Eagle@lemmy.world
      link
      fedilink
      English
      arrow-up
      9
      ·
      edit-2
      11 months ago

      tbh I don’t think it matters, so wherever you feel like doing it. I just leave it where the distro or file manager defaults to: in Ubuntu-based distros that’s /media/$USER/mount-name. For mounts shared across users you could drop the $USER.

      Since FHS doesn’t specify where “non-removable media” should go, I don’t think it makes sense to adopt this recommendation as /media should be removable, but rather, “in case the media IS removable, then mount it to /media/”.

    • zhenbo_endle@lemmy.ca
      link
      fedilink
      English
      arrow-up
      5
      ·
      11 months ago

      I’m also mounting them into /home/user/data while I don’t think hard-coding the user name in the mountpoint is a good idea. Besides, it needs the assumption that I’m the only “human-user” of this computer.

      I may also mount them at /opt/data, but I’m not sure if it’s a good idea

      • callcc@lemmy.worldOP
        link
        fedilink
        arrow-up
        3
        arrow-down
        1
        ·
        11 months ago

        From my humble knowledge I would suggest /var/opt/XXX. It’s the variable part of the /opt hierarchy.

    • pixelscript@lemmy.ml
      link
      fedilink
      English
      arrow-up
      5
      arrow-down
      1
      ·
      11 months ago

      I originally had mine mounted on /, to make them easy to type. But that set one of my highly opinionated friends wretching, so I re-mounted them to /media// to placate him and symlinked them to my home directory instead.

      It’s frustrating how often Linux systems, when approached with a “where is the canonical location for ?” question, have an answer ancient use cases practically no one has anymore, but no satisfying answer for extremely common use cases like permanently mounted backup drives, where to put web server hosted files, or even where to install applications that don’t come from package managers (/opt/? /usr/bin/? /home//.local/?).

    • BronzedBonobo
      link
      fedilink
      English
      arrow-up
      5
      arrow-down
      1
      ·
      11 months ago

      I’m coming more from a server perspective but, fundamentally, all HDDs are “temporary”. Eventually that data might be in a bigger/faster/functioning replacement - so it’s best to treat the drive as something which can always be replaced.

      Continuing that, you might mount to /mnt and then symlink that where you really want it, say …/games. That layer of abstraction allows you to replace the drive without much effect on install. Also allows for expansion via something like mergerfs (*no idea if that’s a good idea for your use cases)

      • callcc@lemmy.worldOP
        link
        fedilink
        arrow-up
        4
        arrow-down
        1
        ·
        11 months ago

        /mnt is explicitly meant to be used as temporary mountpoint for admins. That’s not a good place.

        • BronzedBonobo
          link
          fedilink
          English
          arrow-up
          1
          arrow-down
          2
          ·
          11 months ago

          I’m still learning myself, but I think in a good number of uses cases it qualifies. There are two parts of that explicit definition which seem important, “temporary” and “non-installation”. “Temporary” is the most ambiguous. An array of JBoD storing media files, which can be unplugged really at any time without affecting any system, meets that definition. Game installs or the operating system, less so. I totally get my specific usage may not lend to generic advice. In the interest of me learning, here’s where I started (which advises /mnt): https://perfectmediaserver.com/02-tech-stack/mergerfs/

    • 520@kbin.social
      link
      fedilink
      arrow-up
      3
      ·
      edit-2
      11 months ago

      If it’s just personal files and backups, there’s absolutely nothing wrong with what you’re doing.

      If you had, say, active system config files there, it would make things… complicated to say the least.

    • L3ft_F13ld!@links.hackliberty.org
      link
      fedilink
      arrow-up
      2
      ·
      11 months ago

      Not sure if this is proper procedure since I searched around and didn’t find much, but I’ve got an internal drive just for games mounted at /home/games. Haven’t had any issues so far.