Tiny Core Linux

Tiny Core Base => TCB Talk => Topic started by: jls on January 19, 2011, 03:12:06 AM

Title: tce-load usage could be updated
Post by: jls on January 19, 2011, 03:12:06 AM
 if I type tce-load I see only -w and -i as parameters
Title: Re: tce-load usage could be updated
Post by: jerramy on January 19, 2011, 05:26:15 AM
Yes, I'd really like guidance on the usage of tce-load, and searching in the forums for "tce-load" brings up WAY too many things that aren't what I'm looking for...
Title: Re: tce-load usage could be updated
Post by: jls on January 19, 2011, 05:31:00 AM
u could view /usr/bin/tce-load
Title: Re: tce-load usage could be updated
Post by: curaga on January 19, 2011, 05:39:56 AM
The wiki has a short comparison:
http://tinycorelinux.com/wiki/Package+management+cheat+sheet
Title: Re: tce-load usage could be updated
Post by: jerramy on January 19, 2011, 08:11:55 AM
Thanks for that, I hadn't thought about it being a readable script.  Reading it is a good way to understand what goes into the making and installation of an extension, beyond the unpacking of a squashfs.

So my understanding of the flags (taken from the code, not the usage info, though my understanding of bash is minimal):

-w = Download extension
-i  = Load extension, and add to onboot.lst
-l = Load extension, don't add to ondemand or onboot.lst
-c = Copy files directly into filesystem, instead of using a tcloop and symlinks.
-b = (used by TCL to flag special things needing to be done when booting up)
-o = Place the extension in the OnDemand list.
-s = Supress some message...

What I'm curious about is what advantage is there to using tce-load without the -c flag?  Slightly faster on bootup?  It made me think of a post I saw from someone who was having problems with Wine, where it wasn't finding dlls he put in the most obvious directory, because wine was looking for a relative path (which ended up being down the /tmp/tcloop tree).  What harm is there in making all extensions use the -c flag?  It seems like it would make for a simpler system.
Title: Re: tce-load usage could be updated
Post by: gerald_clark on January 19, 2011, 08:37:42 AM
The default is to loop mount extensions.
The problem with a default -c is that it will copy all the extensions into the filesystem.
This will increase bootup time, and decrease the amount of RAM you have available to run programs.
Title: Re: tce-load usage could be updated
Post by: jerramy on January 19, 2011, 08:45:46 AM
Aren't loop mount extensions also in RAM?  The original files were compressed, it seems like the only possibility for the uncompressed files to be in RAM.  Or does the loop mount system load files into RAM only when the file is opened, or decompress it on the fly on read access?
Title: Re: tce-load usage could be updated
Post by: gerald_clark on January 19, 2011, 09:01:28 AM
No. loop mounted extensions are not in RAM.
Loop mounted extensions exist on persistent storage ( HD or USB ).
They are mounted into the /tmp/tcloop directory.
From here, the executable programs or libraries are symlinked into the appropriate directory.
Symlinks take very little filesystem space.
Title: Re: tce-load usage could be updated
Post by: hiro on January 19, 2011, 09:05:17 AM
Also see core concepts on the web site, specifically copy2fs.
Title: Re: tce-load usage could be updated
Post by: hiro on January 19, 2011, 09:06:16 AM
No. loop mounted extensions are not in RAM.
Loop mounted extensions exist on persistent storage ( HD or USB ).
They are mounted into the /tmp/tcloop directory.
From here, the executable programs or libraries are symlinked into the appropriate directory.
Symlinks take very little filesystem space.
Not in cloud mode.
Title: Re: tce-load usage could be updated
Post by: jerramy on January 19, 2011, 09:16:28 AM
So this goes well beyond the scope of the original topic, but how does squashfs work?  If it's just that the "empty" space has been taken out of inodes, and duplicate inodes are shared, then I could see that this is fairly fast to implement in the filesystem driver.  If on the other hand, the data inside inodes is compressed, it would seem like the driver would have to decompress the data on the fly, which might slow things down a little (though if drive reads are the bottleneck, it might actually speed things up).

Does anyone have a feeling for how the runtime speed performance of the two methods (mount squashfs vs. copy to FS) compare?
Title: Re: tce-load usage could be updated
Post by: hiro on January 19, 2011, 09:56:55 AM
The squashfs extensions are compressed with gzip. I don't experience any difference speed, but in boot time. So mounted squashfs definitely wins.
Title: Re: tce-load usage could be updated
Post by: jerramy on January 19, 2011, 10:02:45 AM
Thanks, that makes it clear for me.
Title: Re: tce-load usage could be updated
Post by: gerald_clark on January 19, 2011, 10:07:01 AM
Yes. In cloud mode, the squashfs sits in the filesystem.
Even in cloud mode, the loop mounted squashfs takes less room than the uncompressed tree copied into the filesystem, so there is still a RAM savings.

Cloud mode is so limited that most users quickly convert to a TCE/Install mode.
Title: Re: tce-load usage could be updated
Post by: hiro on January 19, 2011, 02:37:21 PM
I'm not even so sure about that. With ramzswap the overhead might eat it up again.
Title: Re: tce-load usage could be updated
Post by: hiro on January 19, 2011, 02:38:41 PM
In a way I like the cloud mode. Quite usable together with /opt
Title: Re: tce-load usage could be updated
Post by: jerramy on January 19, 2011, 10:56:09 PM
Cloud mode seems ideal if you have tons of ram, and no storage.  Like I got 4GB of ram, but only 32M of storage...  Single board computers maybe, though most have 4GB of FLASH on them as well.



Title: Re: tce-load usage could be updated
Post by: tinypoodle on January 20, 2011, 03:09:23 AM
Cloud mode is so limited that most users quickly convert to a TCE/Install mode.

Not sure what limitations exactly you have in mind, but if the suggestion as discussed in thread http://forum.tinycorelinux.net/index.php?topic=8489.0 could be implemented, then that possibly could lead to a mode with less limitations, while keeping all the benefits of mounting extensions from tmpfs.
Title: Re: tce-load usage could be updated
Post by: tinypoodle on January 20, 2011, 03:14:53 AM
Cloud mode seems ideal if you have tons of ram, and no storage.  Like I got 4GB of ram, but only 32M of storage...  Single board computers maybe, though most have 4GB of FLASH on them as well.

Those specs seem like an ideal use case for TC.
On 32MB you would have enough space to load TC base and only those extensions required to access LAN and/or WLAN plus store a backup of dynamical data   :D