Re: Overfull Filesystems how to solve?

[Tapani Tarvainen <ipfire@tapanitarvainen.fi>]

[-- Attachment #1: Type: text/plain, Size: 3525 bytes --]

On Sun, Jan 19, 2020 at 06:16:25PM +0000, Michael Tremer (michael.tremer(a)ipfire.org) wrote:

> > On 18 Jan 2020, at 10:30, Tapani Tarvainen <ipfire(a)tapanitarvainen.fi> wrote:
> > 
> > On Sat, Jan 18, 2020 at 10:57:08AM +0100, Jonatan Schlag (jonatan.schlag(a)ipfire.org) wrote:
[...]
> >> Furthermore, as the systems become bigger (eg. moving python3 to the
> >> core) this problem will become more relevant to us. So I would like to
> >> start a discussion on how to solve this. Moving things to /var can only
> >> be a temporary solution. Should we force a reinstallation, which solves
> >> the root of the problem?

> > One obvious alternative would be using LVM. Combined with a suitable
> > filesystem like ext4, it makes resizing filesystems pretty trivial.
> > It does add a bit of overhead but not enough to matter here, IMHO.
> > 
> > Another would be using ZFS, which solves the problem a bit differently
> > (and arguably better), but it's not included in mainline kernels due
> > to licensing issues so it would add maintenance work.
> > 
> > FWIW, I like LVM and tend to use it in all systems where disk space
> > and allocation is likely to change.
 
> LVM is generally a good idea. However it is not implementable on
> systems that are already running out of space.

True, unless you are doing a reinstall anyway. And it would help
in the long run.

> Back in the day it seemed to be a good idea to have different
> partitions for / and /var. New systems will now just have one
> partition for /. Simply put, you will have all the space your
> hardware allows you and if you are running out, you are running out.

Although I see little use in having separate /var, under some
circumstances having one filesystem fill up might not be as disastrous
as filling / up. E.g., it might well make sense to have /var/log or
/tmp as separate filesystems. (I've seen firewalls DOSsed by
overflowing logs and all kinds of systems filling up /tmp because of
some process writing there went haywire.) It would require some
thinking about which directories would be likely to fill up
temporarily in a fixable way.

LVM also makes it easy to add another disk quickly without
reinstalling everything. Or even replacing the system disk with
a bigger one, having two disks connected only temporarily.

On the other hand, having a single / filesystem has the advantage of
simplicity, and in case of disk filling up in a permanent kind of way
(as opposed to temporary, fixable situations) it is the best one can
do, as you say.

It would also be possible to get the best of both worlds by using LVM
and still having just / filesystem initially or as an option, maybe
depending on disk size or user preference.

> ZFS is not available on Linux.

It's not in mainline kernels as I noted but it is certainly available
in the sense that OpenZFS can be installed (e.g., Ubuntu and Proxmox
build their default kernels with ZFS). I would still prefer LVM though.

Anyway, I may have misunderstood the context. If we are talking only
about what to do with a current installations that run out of space in
root (/) but have plenty left in /var, reinstallation seems like the
obvious thing to do. (Merging separate / and /var into one filesystem
without reinstalling would be technically possible but probably not
worth the trouble.)

LVM/ZFS/whatever was only an idea for the long term, worth considering
in the next major version perhaps.

-- 
Tapani Tarvainen