Thanks for the quick answer.
I will contact Harald Schilly.
On 30 Jan., 20:01, Robert Bradshaw <rober...@math.washington.edu>
wrote:
>
>
> Just to be sure I'm understanding you, the primary advantage of this
> vs. downloading a binary .tar is that its size is smaller (and perhaps
> it's quicker, though less standard, to mount an image than unpack a
> tar)?
>
I think it should be more standard. SquashFS is built in the linux
kernel
for over a year now.
(http://www.h-online.com/open/news/item/Btrfs-and-Squashfs-merged-into-
Linux-kernel-739613.html)
But this is not the main point. You can mount it or! unpack it
== unsqashfs sage-x.y.z.sqfs -d /usr/local/sage-x.y.z ==.
All the functionality is built in and because it is used and tested
for so long time
(all linux live cds are working with it), it is one of the most
optimized parts in the linux world.
It was build for reading a linux system from slow small memory (old
flash, cdrom), while holding
the system usable fast. It uses all the processors and the RAM the
system has. On dual core
processors with hyperthreading it is 3 times faster than tar.gz. (just
see the P.S.)
And using sage from the sqfs file at a machine with enough ram is as
fast as it would be uncompressed.
And there is one more Pro for squashFS, the builtin update
functionality. Maybe you just want to add a small package to your sage
version. of course you have to unpack it (tar.bz2 or sqfs), where sqfs
is much faster.
Then you install your package and later (you want to have it on your
netbook or classroom pcs) you have to pack
it again. While at tar.bz2 you have to pack all the files, sqfs
realizes that there is already a sqfs file and just updates the
differences.
But there is a little contra too. The version 4.0 is incompatible with
3.3 used before (just the mounting feature,
packing and unpacking works). But this is not a big problem because
binary versions are bound to a special
linux version anyway.
Pro:
-more system independent because it is built in the kernel even on
quite a lot of embedded or arm linux
-little endian and big endian are no problems too
-parallel processing optimized
-speed and memory optimized mount functionality on (almost?) all
linux systems
-smaller file size
-backup functionality
Con:
- 3.3<->4.0 version problem on old linux systems, so you have to
create the sqfs at the system you built it
or you have to convert it later
Frank Polte
P.S. This is the output on my dual P4 Xeon 2.4 Ghz Desktop (built year
2000). Creating a sqfs file is faster
than to copy the files to another harddisk. But it costs quite a lot
of computing power, what copying doesn't need.
terminal command$$: time mksquashfs /usr/local/sage-4.3.1/ sage.sqfs
Parallel mksquashfs: Using 4 processors
Creating 4.0 filesystem on sage.sqfs, block size 131072.
[========================================================================================================================================|]
61513/61513 100%
Exportable Squashfs 4.0 filesystem, data block size 131072
compressed data, compressed metadata, compressed fragments
duplicates are removed
Filesystem size 667323.53 Kbytes (651.68 Mbytes)
38.38% of uncompressed filesystem size (1738820.75 Kbytes)
Inode table size 543151 bytes (530.42 Kbytes)
29.51% of uncompressed inode table size (1840604 bytes)
Directory table size 629682 bytes (614.92 Kbytes)
45.53% of uncompressed directory table size (1382928 bytes)
Number of duplicate files found 7082
Number of inodes 56034
Number of files 52495
Number of fragments 3588
Number of symbolic links 124
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 3415
Number of ids (unique uids + gids) 1
Number of uids 1
root (0)
Number of gids 1
root (0)
real 4m33.215s
user 11m12.790s
sys 0m32.210s
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
