Hi,
On 20 Jan 2020, at 11:39, Tapani Tarvainen ipfire@tapanitarvainen.fi wrote:
On Jan 20 10:38, Michael Tremer (michael.tremer@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. :-)
True, but we could put the work into IPFire 3 which would have more users.
With limited resources we need to make stupid decisions like this.
[...] 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.
I didn’t mean to be too harsh on the developers, but the last news I heard was that many of them left the project.
Fedora planned to make it the default FS many many years ago and it still did not happen. I suppose nobody is waiting for it any more.
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.
We have walked through /lib/firmware before. Old hardware does not need to load firmware. It either does not need it at all or there is a ROM on the hardware itself. It is the modern stuff that is still in use where they removed the ROM to save cost. We have estimated that we might be able to save 5% of disk space, but it is simply not worth it to put the work in every time we update the firmware package to save a couple of megabytes.
-Michael
-- Tapani Tarvainen