moss: Prime vfs cache on boot via systemd service #548
+26
−2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ermo
force-pushed
the
moss-prime-vfs-cache-at-boot
branch
from
87b2c75 to
77f974d
Compare
ermo
force-pushed
the
moss-prime-vfs-cache-at-boot
branch
from
77f974d to
4897a90
Compare
This should serve to make the first blit after boot run against a hot vfs cache, which should improve the performance of the first blit for Serpent OS systems installed to ext4 or f2fs roots in particular. Neither ext4 nor f2fs blits will be as fast as xfs blits, so xfs currently remains the recommended root filesystem for Serpent OS. Additionally, include a oneshot .service for testing the time to prime w/ a cold vfs cache. Signed-off-by: Rune Morling <[email protected]>
ermo
force-pushed
the
moss-prime-vfs-cache-at-boot
branch
from
4897a90 to
e628d53
Compare
ermo
added a commit
to serpent-os/lichen
that referenced
this pull request
Jan 13, 2025
Note that, in addition to being slow for cold blits, ext4 only supports 65k hardlinks per file, and it has a limit of 4k for combined extended attribute data as well. Given we are looking at supporting SELinux, there is a very real chance that we are artificially (and knowingly) limiting ourselves by offering ext4 as a rootfs for Serpent OS. NB: serpent-os/recipes#548 is now up as a way to help mitigate the ext4 and f2fs cold blit slowness until we figure out a better solution. Signed-off-by: Rune Morling <[email protected]>
ermo
added a commit
to serpent-os/lichen
that referenced
this pull request
Jan 13, 2025
Note that, in addition to being slow for cold blits, ext4 only supports 65k hardlinks per file, and it has a limit of 4k for combined extended attribute data as well. Given we are looking at supporting SELinux, there is a very real chance that we are artificially (and knowingly) limiting ourselves by offering ext4 as a rootfs for Serpent OS. NB: serpent-os/recipes#548 is now up as a way to help mitigate the ext4 and f2fs cold blit slowness until we figure out a better solution. Signed-off-by: Rune Morling <[email protected]>
|
On an old 4790K w/a SATA-600 SSD with ext4 rootfs, I got the following numbers: Hot vfs cache install blit (setup+teardown + blit): 13s-ish Video below is dinky, but does the job. ext4-hot-and-cold-vfs-cache-blit-2025-01-13.webm |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This should serve to make the first blit after boot run against a hot vfs cache, which should improve the performance of the first blit for Serpent OS systems installed to ext4 or f2fs roots in particular.
Neither ext4 nor f2fs blits will be as fast as xfs blits, so xfs currently remains the recommended root filesystem for Serpent OS.
Additionally, include a oneshot .service for testing the time to prime w/ a cold vfs cache.
Status after cold boot on xfs: