CageFS inflated the git-core Directory from 84MB to 3.2GB in skeleton.

[Panda]

I am new to CloudLinux so I made a test server to play around a bit.
I used a small HD, only 20GB as it is just a sandbox to play around.

When I installed cageFS, a disk warning was triggered
I know cageFS takes space but it took too much space!

The cause was confirmed with stat.

In the real cPanel Git directory, files such as git-write-tree, git-worktree, and git-status shared the same inode and had a high hard-link count, meaning they were multiple names pointing to the same physical file.
In the CageFS skeleton, those same files had separate inodes and a hard-link count of 1, meaning CageFS had copied them as full separate files.

That inflated Git’s helper binaries from about 84 MB to 3.2 GB.

I don't know if this is a known issue?
My Host told me to talk to CloudLinux about it so I thought I would post it here.

I just renamed the bad cageFS git-core directory, copied the original git-core into skeleton and then deleted the bad one, saving a few GB in storage space.

[bogdan.sh]

Hi Panda,

Great catch - your inode analysis is spot on. This is genuine disk usage, not the usual "the skeleton is virtual" situation. cPanel's bundled git ships its git-core commands as hardlinks to a single binary, and when CageFS builds the skeleton it copies them as independent files, losing that de-duplication so ~84 MB expands into ~3.2 GB.

We've reproduced it on our side and confirmed it's a CageFS bug; it's now filed with our team. (It's specific to hardlinked layouts like cPanel's git modern upstream git uses symlinks, which CageFS handles fine.)

Your workaround (replacing the skeleton git-core with a hardlink-preserving copy) is fine as an interim fix just note the daily cagefsctl --force-update cron may rebuild and re-inflate it, so re-check afterward. If git isn't needed inside users' cages removes it cleanly:

cagefsctl --delrpm git && cagefsctl --force-update && cagefsctl -M

Filled a bug CLOS-4631. Thanks for the detailed report!

Best regards,

[bogdan.sh]

Hi Panda,

Great catch - your inode analysis is spot on. This is genuine disk usage, not the usual "the skeleton is virtual" situation. cPanel's bundled git ships its git-core commands as hardlinks to a single binary, and when CageFS builds the skeleton it copies them as independent files, losing that de-duplication so ~84 MB expands into ~3.2 GB.

We've reproduced it on our side and confirmed it's a CageFS bug; it's now filed with our team. (It's specific to hardlinked layouts like cPanel's git modern upstream git uses symlinks, which CageFS handles fine.)

Your workaround (replacing the skeleton git-core with a hardlink-preserving copy) is fine as an interim fix just note the daily cagefsctl --force-update cron may rebuild and re-inflate it, so re-check afterward. If git isn't needed inside users' cages removes it cleanly:

cagefsctl --delrpm git && cagefsctl --force-update && cagefsctl -M

Filled a bug CLOS-4631. Thanks for the detailed report!

Best regards,