WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: tce-load usage could be updated  (Read 3845 times)

Offline jls

  • Hero Member
  • *****
  • Posts: 2135
tce-load usage could be updated
« on: January 19, 2011, 03:12:06 AM »
 if I type tce-load I see only -w and -i as parameters
dCore user

Offline jerramy

  • Jr. Member
  • **
  • Posts: 76
Re: tce-load usage could be updated
« Reply #1 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...

Offline jls

  • Hero Member
  • *****
  • Posts: 2135
Re: tce-load usage could be updated
« Reply #2 on: January 19, 2011, 05:31:00 AM »
u could view /usr/bin/tce-load
dCore user

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10957
Re: tce-load usage could be updated
« Reply #3 on: January 19, 2011, 05:39:56 AM »
The only barriers that can stop you are the ones you create yourself.

Offline jerramy

  • Jr. Member
  • **
  • Posts: 76
Re: tce-load usage could be updated
« Reply #4 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.

Offline gerald_clark

  • TinyCore Moderator
  • Hero Member
  • *****
  • Posts: 4254
Re: tce-load usage could be updated
« Reply #5 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.

Offline jerramy

  • Jr. Member
  • **
  • Posts: 76
Re: tce-load usage could be updated
« Reply #6 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?

Offline gerald_clark

  • TinyCore Moderator
  • Hero Member
  • *****
  • Posts: 4254
Re: tce-load usage could be updated
« Reply #7 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.

Offline hiro

  • Hero Member
  • *****
  • Posts: 1217
Re: tce-load usage could be updated
« Reply #8 on: January 19, 2011, 09:05:17 AM »
Also see core concepts on the web site, specifically copy2fs.

Offline hiro

  • Hero Member
  • *****
  • Posts: 1217
Re: tce-load usage could be updated
« Reply #9 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.

Offline jerramy

  • Jr. Member
  • **
  • Posts: 76
Re: tce-load usage could be updated
« Reply #10 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?

Offline hiro

  • Hero Member
  • *****
  • Posts: 1217
Re: tce-load usage could be updated
« Reply #11 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.

Offline jerramy

  • Jr. Member
  • **
  • Posts: 76
Re: tce-load usage could be updated
« Reply #12 on: January 19, 2011, 10:02:45 AM »
Thanks, that makes it clear for me.

Offline gerald_clark

  • TinyCore Moderator
  • Hero Member
  • *****
  • Posts: 4254
Re: tce-load usage could be updated
« Reply #13 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.

Offline hiro

  • Hero Member
  • *****
  • Posts: 1217
Re: tce-load usage could be updated
« Reply #14 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.