From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Overfull Filesystems how to solve? Date: Mon, 20 Jan 2020 11:49:14 +0000 Message-ID: In-Reply-To: <20200120113955.GC15914@tehanu.it.jyu.fi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8209435386893042449==" List-Id: --===============8209435386893042449== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > On 20 Jan 2020, at 11:39, Tapani Tarvainen wr= ote: >=20 > On Jan 20 10:38, Michael Tremer (michael.tremer(a)ipfire.org) wrote: >=20 > [...] >=20 >> 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=E2=80=99s 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. >=20 > 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. >=20 > 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. >=20 >> We always had LVM and RAID on the roadmap for IPFire 3. >=20 > Good. >=20 >> Actually nobody has asked for this ever. So although it would be >> nice, there is no demand for it. >=20 > I would use it if it was available. (I'd probably make at least > /var/tmp and /var/log their own filesystems.) >=20 >> I guess that is mainly because IPFire=E2=80=99s 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. >=20 > That may well be true. >=20 >> The code in the installer is actually quite nice and clean. I >> refactored it a couple of years ago and added support for RAID1. >>=20 >> I guess that could be extended to support LVM, but again, I am not >> sure if that will ever have any users. >=20 > 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. >=20 >> [...] 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). >=20 > Agreed. >=20 >> I suppose btrfs is properly dead now. >=20 > That's perhaps a bit premature, but it's not looking too healthy > either. I didn=E2=80=99t 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. >=20 > Yes. More's the pity. >=20 >> 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. >=20 > Yes. In some situations there are noticeable speed differences, but > disk speed is rarely a problem in a firewall. >=20 >> The bloat is somewhere else actually. We are shipping almost half a >> gigabyte of firmware for various hardware. That all just adds up. >=20 > 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 lo= ad firmware. It either does not need it at all or there is a ROM on the hardw= are itself. It is the modern stuff that is still in use where they removed th= e ROM to save cost. We have estimated that we might be able to save 5% of dis= k space, but it is simply not worth it to put the work in every time we updat= e the firmware package to save a couple of megabytes. -Michael > --=20 > Tapani Tarvainen --===============8209435386893042449==--