Tiny Core Base > TCB Q&A Forum
Understanding tc: Why is “mount on boot” not super fast?
yvs:
--- Quote from: Stefann on August 29, 2024, 12:38:40 AM ---- this mounting of a compressed archive probably requires disk operation to read the full archive file.
--- End quote ---
Not sure if that's related: on Ubuntu with its squashfs use (for snaps) there were many discussions of use different compression formats (for example lzo zstd xz etc.) trading-of between size and performance
mocore:
--- Quote from: yvs on August 29, 2024, 05:35:48 AM ---Ubuntu with its squashfs use (for snaps) there were many discussions of use different compression formats (for example lzo zstd xz etc.) trading-of between size and performance
--- End quote ---
some perhaps (historically) relevant content on that subject linked in the below quote
--- Quote from: mocore on September 03, 2019, 09:35:54 AM ---
wrt squashfs and compression
iv just found this [linked below] post lamenting the state of Ubuntu's Snap single-threaded decompression
... "scripts to recreate these measurements are included" ! .. if any one with similar hw is interested in making comparison?
https://forum.snapcraft.io/t/squashfs-is-a-terrible-storage-format/9466
--- End quote ---
Stefann:
head of the optional folder sorted on size.
Indeed gcc is super big
-> I definitely can do with a later load of that.
Would not be surprised if that is eating 50% of boottime.
To my (kind of) surprise samba3 is also big
-> One of the first things I use, cannot load later.
>> guess samba did not succeed in "having small footprint" like many other apps.
mmmh... I did. not install perl. guess this is a dependancy somewhere
ouch... I have 2 pythons, I can get rid of one.
After that it becomes peanuts
Will need to find time in weekend to explore
--- Code: ---tc@huis:/mnt/sda1/tce/optional$ ls -Sl
total 215860
-rw-rw-r-- 1 tc staff 61710336 Aug 17 06:26 gcc.tcz
-rw-rw-r-- 1 tc staff 35917824 Aug 17 06:25 samba3.tcz
-rw-rw-r-- 1 tc staff 16601088 Aug 17 06:25 perl5.tcz
-rw-rw-r-- 1 tc staff 16556032 Aug 17 06:25 python3.6.tcz
-rw-rw-r-- 1 tc staff 15740928 Aug 17 06:25 python3.9.tcz
-rw-rw-r-- 1 tc staff 6410240 Aug 17 06:25 binutils.tcz
-rw-rw-r-- 1 tc staff 4218880 Aug 17 06:25 php-8.3-dev.tcz
-rw-rw-r-- 1 tc staff 3239936 Aug 17 06:25 php-8.3-ext.tcz
-rw-rw-r-- 1 tc staff 3125248 Aug 17 06:25 glibc_base-dev.tcz
-rw-rw-r-- 1 tc staff 3063808 Aug 17 06:25 glibc_gconv.tcz
-rw-rw-r-- 1 tc staff 2994176 Aug 17 06:25 gcc_libs-dev.tcz
-rw-rw-r-- 1 tc staff 2834432 Aug 17 06:25 openssl.tcz
-rw-rw-r-- 1 tc staff 2764800 Aug 17 06:26 realvnc.tcz
--- End code ---
Rich:
Hi Stefann
I don't think size is the main issue. I think it's the number
of symlinks that need to be created. That is a function of
how many files are in the extension.
Stefann:
Hi @rich,
I think you are right,
I did do some reading on squashfs, it’s indeed intended to be a fast compressed filesystem (you of course knew that :) ), and what’s more… the meta data is kept in some special place. So.. not the full file needs to be read to identify all mount points.
Anyway… the practical implication is probably less.
Biggest file gcc is 61MB, 7th ranking big file is php with 4MB. I guess that the amount of mountpoints for php will be similarly smaller.
I will just do a test this weekend by removing gcc from the onboot list and see what happens.
Note: by now it’s just for fun and learning. There is hardly a real need to do this.
Having said that…. if it gives a significant gain.. I will probably remove gcc from the onboot list permanently and load it via bootlocal.sh as @centralware suggested. A single line in bootlocal.sh i probably consider worth the “clutter deviating it from standard”.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version