tce-load usage could be updated

[jls]

 if I type tce-load I see only -w and -i as parameters

[jerramy]

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...

[jls]

u could view /usr/bin/tce-load

[curaga]

The wiki has a short comparison:
http://tinycorelinux.com/wiki/Package+management+cheat+sheet

[jerramy]

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.

[gerald_clark]

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.

[jerramy]

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?

[gerald_clark]

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.

[hiro]

Also see core concepts on the web site, specifically copy2fs.

[hiro]

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.

[jerramy]

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?

[hiro]

The squashfs extensions are compressed with gzip. I don't experience any difference speed, but in boot time. So mounted squashfs definitely wins.

[jerramy]

Thanks, that makes it clear for me.

[gerald_clark]

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.

[hiro]

I'm not even so sure about that. With ramzswap the overhead might eat it up again.