• limelight79@lemm.ee
      link
      fedilink
      arrow-up
      2
      ·
      8 months ago

      I can definitely see doing that on a server many people are using. For my personal server, I used to do that, but in the end I couldn’t find much benefit, and only headache (“ahhhh / is short on space because I forgot to clean up old kernels…”).

      • scratchandgame@lemmy.ml
        link
        fedilink
        Tiếng Việt
        arrow-up
        3
        ·
        edit-2
        8 months ago

        I think it would save you someday, when there is nothing writing in /usr so the writing in /home would not cause much damage. On a system with a huge root partition, an incomplete writing might damage the whole filesystem.

        Fsck would be faster. newfs (mkfs) would be faster. I found NetBSD spend so much time when it do newfs a 32G root partition (installing NetBSD in hyper-v).

        Also for the /tmp partition, we can use memory filesystem (tmpfs) if we have 4G of RAM or more, instead of physical disk to store things that are cleaned on reboot.

        • limelight79@lemm.ee
          link
          fedilink
          arrow-up
          2
          ·
          8 months ago

          I’m not saying it can’t happen, but I’ve been using Linux since the late 90s and have never had a problem with an incomplete write damaging the file system, or really anything else (except for a recent incident when a new motherboard decided to overwrite the partition tables on my RAID5 array, but that’s a different story). And I have UPSs on the server and desktop, and of course the laptop has a battery in it, so the risk of sudden power loss is extremely low.

          The /tmp thing in RAM is interesting. I was reconfiguring my server’s drive the other day, because I didn’t originally allocate enough space to /var - it worked fine for years until I started playing with plex, jellyfin, and Home Assistant (the latter due to the database size). I was shocked to find /tmp only had a few files in it, after running for years. I think I switched the server to Debian in 2018 or 2019, but that’s just a guess based on the file dates I’m seeing. Maybe Debian cleans the /tmp partition regularly.