• scratchandgame@lemmy.ml
    link
    fedilink
    Tiếng Việt
    arrow-up
    3
    ·
    edit-2
    9 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
      ·
      9 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.