• Comments
  • Reasoning for seperating /var from /

    Posted on

    There is a commonly held wisdom that /var should by default be seperated from the root partition (for example https://access.redhat.com/site/articles/10332).

    While reviewing our current kickstart setup (seperate /, /var, /tmp and /home provided by NFS) I came to question why / was seperated from /var.

    Asking around the building, the commonly stated reason tended to be that /var could easily be filled by a (possibly misbehaved) application, and that if it wasn't seperate from / the filling of / would cause a kernel would panic. Though, in my (limited) experience filling /, I haven't witnessed this - I have found references to this occuring in years long past in kernel and OS versions long out of use.

    Supposing we had to make the choice between a 20GB /, or a 15GB / and 5GB /var, the latter case has the advantage of isolating applications filling / from interferring from /var or vis versa, but increases the chances that a filesystem will fill.

    The seriousness of a filled /var is already quite substantial - systems will not function properly, I imagine / filling at the time would only be a small incremental danger. So it becomes a tradeoff, one big partition for / and /var lowers the chance that /var will fill due to applications writing to /var but increases the consequence of /var filling (being that / will fill at the same time.)

    Is there some additional risk to / filling that I haven't observed? Is a full / any more likely to cause a kernel panic than a full /var? (If there is any kernel panic? All that came to mind was if device nodes couldn't be created, some issues could manifest - but if that were the only means of this rumoured kernel panic then perhaps we should be putting /dev on the seperate filesystem).

    Naturally there are case specific reasons to split off /var (or a subset of /var) into its on file system, though in the general case I'm wondering what the reasons are.

    by

    points

    Responses

    Red Hat
    © 2025 Red Hat, Inc.