Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Papirus icon theme uses to many inodes in filesystem. #3563

Open
darkshram opened this issue Oct 3, 2023 · 7 comments
Open

Papirus icon theme uses to many inodes in filesystem. #3563

darkshram opened this issue Oct 3, 2023 · 7 comments

Comments

@darkshram
Copy link

Papirus Icon theme has grown with over +100k files. This means, it will use over 100k inodes in any filesystem. Systems with relatively small partitions will not be able to install papirus icon theme because of this even if there is plenty space available. Example: a 30 GB partition for / on any Linux distribution, with a lot of applications installed or other large icon themes, will have issues to install (system-wide) Papirus or will exhaust (o near exhaust) the inodes capacity of the filesystem in some scenarios and inadvertently DoS the filesystem just by installing papirus icon theme.

Strongly suggest to adopt a similar scheme as done for Numix: They have a core theme and a complementary applications-only theme. Or to split icons for proprietary applications into a separate git repository. Or at least to warn users in the README.md file about the big number of installed files and potential inode capacity exhaustion in some filesystems.

@SmartFinn
Copy link
Member

It doesn't look like a real problem. I have installed my system on 20G ext4 filesystem and never got the issue. Yeah, the icon theme is huge, but how splitting the theme to a few packages make it smaller? The only rational thing that I can do, it's move ePapirus and ePapirus-Dark to another package.

Here is how much Inodes requires Papirus icon theme for installation on small partitions (ext4 defaults):

Filesystem      Inodes  IUsed   IFree IUse%
/dev/nbd0p1     655360 118066  537294   19% # 10GB
/dev/nbd0p1    1310720 118066 1192654   10% # 20GB
/dev/nbd0p1    1966080 118066 1848014    7% # 30GB
/dev/nbd0p1    2621440 118066 2503374    5% # 40GB

@darkshram
Copy link
Author

Some scenarios probably will not do as well. It depends on the usage of the filesystem and whatever is installed/stored there. After several years of usage, final users will have installed or stored a lot of things.

Example (the incident originating this issue): A few hours ago, a user of my Linux distribution contacted me because he could not install papirus (see attached image). He had a lot of files and applications for different reasons in a 30GB partition (/). Made him uninstall as much unused packages as possible with rpmorphan. After system cleaning, he finally was able to install the RPM package for papirus. But just a few minutes later, contacted me again, now because he could not install back some software he needed, now because papirus exhausted the inodes capacity of his 30 GB partition for /. Obviously, having papirus installed system-wide for him (in this particular scenario) was not a good idea, and had to made him switch to another (not as pretty) icon theme with less files (Tela icon theme also has three regular, dark and light variants, but has only +42k files) and advised him to regularly check with df -i.

photo_2023-10-02_20-23-57

A cleaver warning about the number of files installed by Papirus icon theme would be a good idea. Installing packages with over +100k files are not exactly a common thing to do (unless you install complete TexLive).

As a workaround for my Linux distribution, most likely we will have to split Papirus-Dark and Papirus-Light from papirus-icon-theme package into their own RPM packages to avoid similar issues in the future.

@meybonomme
Copy link

meybonomme commented Oct 7, 2023

The only rational thing that I can do, it's move ePapirus and ePapirus-Dark to another package.

That's a very good idea, because only Pantheon desktop needs these icons.

@johnlepikhin
Copy link

Systems like Nix or Guix stores multiple snapshots of the packages, which have grouped into generations of profiles (sort of OS snapshots). Each generation organized via symlinks to single files. Thus, after installing Papyrus icons set and making some OS snapshots, I've got 30M inodes on my disk and 100% of inodes usage.

So, in some cases it is actually the problem.

@SmartFinn
Copy link
Member

@johnlepikhin seems you have chosen the wrong filesystem for your system. I recommend you to use filesystem with dynamic inodes allocations, like Btrfs, ZFS, and XFS.

Also, 30000000 / 118066 = 254 snapshots, something wrong with your use case.

@johnlepikhin
Copy link

@SmartFinn I use what I use for other important reasons.

Yes, I had plenty "snapshots" of this package, by design. OS reference counter and lazy GC for unused items (i.e. installed packages versions, built profiles). GC is triggered when there is low free space measured bytes, but not in inodes. Sure, it has to be implemented in distro core utils too. Anyway, I ran into the problem after I added Papyrus icon theme to my profile. After removing icons pack:

$ find -L ~/.guix-home/profile/|wc -l
190085

That is, I need 190k inodes to get full-featured desktop/IDE/etc. with 200+ packages installed. I believe such inodes usage is common for most of the users. Icons pack that requires as half as the rest of desktop installation doesn't look well-organized, especially since that there are a lot of ways to split the pack effectively. For Guix, probably I will patch a manifest to generate a separated set of packages, but the problem will remain.

@SmartFinn
Copy link
Member

SmartFinn commented Oct 15, 2023

It seems to me, I have to remove the whole Papirus icon theme to make you happy 🥲

Btw, icon-theme-papirus snap package uses only 1 inode. Just saying.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants