Re: Overfull Filesystems how to solve?

[Tapani Tarvainen <ipfire@tapanitarvainen.fi>]

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

On Jan 20 10:38, Michael Tremer (michael.tremer(a)ipfire.org) wrote:

[...]

> I have no idea how we can slice the disk into correctly sized
> slices. No matter how long we thought about that, we always had a
> unsatisfactory solution for some users. If we would have simply
> increased the size of the / partition, then we would have made more
> than 2GB of space a requirement. But is (let’s say) 4GB enough? Do
> we need 8GB in the future? The /boot partition used to be 20MB
> because a kernel was less than 1MB including the initramdisk. Right
> now, we are allocating 128MB. That is x5 the space. The initramdisk
> alone is now over 20MB. This is an example that should illustrate
> how we cannot use figures from right now because they might be
> totally wrong in a couple of years.

Yes. But of course that's exactly where LVM helps: partition sizes can
be adjusted as needed. Even /boot isn't a problem anymore now that
Grub understands LVM.

Even so, multiple partitions do add complexity and overhead, and
especially with a small disk most users probably would be better off
with a single filesystem. Though even then having LVM under it would
not cost much and it might save the day in some situation.

> We always had LVM and RAID on the roadmap for IPFire 3.

Good.

> Actually nobody has asked for this ever. So although it would be
> nice, there is no demand for it.

I would use it if it was available. (I'd probably make at least
/var/tmp and /var/log their own filesystems.)

> I guess that is mainly because IPFire’s add-ons are becoming less
> and less popular. Not because IPFire itself is becoming less popular
> - quite the opposite actually, but because of those services are
> easier to install in a virtual machine somewhere. Either in the
> cloud, a Raspberry Pi or simply as a VM on the IPFire box itself.

That may well be true.

> The code in the installer is actually quite nice and clean. I
> refactored it a couple of years ago and added support for RAID1.
>
> I guess that could be extended to support LVM, but again, I am not
> sure if that will ever have any users.

I predict it would have at least one user. :-)

> [...] I am very very very careful to include anything into our
> kernel that we cannot maintain ourselves (and we simply do not have
> the expertise or time to maintain a file system).

Agreed.

> I suppose btrfs is properly dead now.

That's perhaps a bit premature, but it's not looking too healthy
either.

> ZFS does not look like it is ever going to be in mainline Linux
> ever.

Yes. More's the pity.

> Ext4 and XFS have caught up now, too. The advantages of things like
> btrfs have become almost nihilated for most users. They are both
> fast and robust and very very well tested. They just work and we do
> not have to worry about them I suppose. It literally does not matter
> what FS you are using for IPFire. They all perform exactly the same.

Yes. In some situations there are noticeable speed differences, but
disk speed is rarely a problem in a firewall.

> The bloat is somewhere else actually. We are shipping almost half a
> gigabyte of firmware for various hardware. That all just adds up.

Right. Just dropping stuff for hardware that isn't supported anyway
should be fairly easy and probably go a long way in solving the issue.

-- 
Tapani Tarvainen