From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tapani Tarvainen To: development@lists.ipfire.org Subject: Re: Overfull Filesystems how to solve? Date: Mon, 20 Jan 2020 13:39:55 +0200 Message-ID: <20200120113955.GC15914@tehanu.it.jyu.fi> In-Reply-To: <8E45A657-5E3D-4AD5-8211-29E4990735B8@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1988389374458026855==" List-Id: --===============1988389374458026855== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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 --===============1988389374458026855==--