Bug 34636 - image file as sparse file
image file as sparse file
Status: CLOSED WONTFIX
Product: Z_Univention Corporate Client (UCC)
Classification: Unclassified
Component: Image management
unspecified
Other Linux
: P5 enhancement
: UCC 3.x
Assigned To: UCC maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-04-24 16:11 CEST by Felix Botner
Modified: 2023-06-28 10:32 CEST (History)
3 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): Roadmap discussion (moved)
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Botner univentionstaff 2014-04-24 16:11:14 CEST
Our image files are already created as sparse files in ucc-image (dd ... seek=...) but after copying(wget, rsync, etc)/compression(xz) the image file looses its sparse feature.

Seems that we could use a tar archiv (instead of xz) to keep the sparse feature.

tar Scvpzf sparsefile.tar sparsefile
tar xzSpf  sparsefile.tar

Copying the tar file (from the image server to ucs and from ucs to the ucc clients) will not destroy the sparse feature.

This would help us to reduce the amount of data for the rollout and the time to create image (xz is very slow)


http://linuxtechres.blogspot.de/2010/10/how-to-deal-with-sparse-files.html
Comment 1 Felix Botner univentionstaff 2014-04-24 17:32:07 CEST
(In reply to Felix Botner from comment #0)
> Our image files are already created as sparse files in ucc-image (dd ...
> seek=...) but after copying(wget, rsync, etc)/compression(xz) the image file
> looses its sparse feature.
> 
> Seems that we could use a tar archiv (instead of xz) to keep the sparse
> feature.

xz compression already handles sparse files by default (xz tries to make the file sparse). 

-> du -h ucc-1.0-rev3-desktop-image.img.xz 
3,1G    ucc-1.0-rev3-desktop-image.img.xz

-> ls -lah ucc-1.0-rev3-desktop-image.img 
-rw-r--r-- 1 root root 15G 24. Apr 15:29 ucc-1.0-rev3-desktop-image.img

-> du -h ucc-1.0-rev3-desktop-image.img
7,3G    ucc-1.0-rev3-desktop-image.img

Also rsync -S (sparse) from the UCC client dosn't help, rsync has to read all the data from the server, it just makes the file smaller on the UCC client, but we don't need that:

-> time rsync -Sa \
/var/lib/univention-client-boot/ucc-1.0-rev3-desktop-image.img .

real 4m26.081s
user 1m52.100s
sys  1m13.376s

-> time rsync -a \
/var/lib/univention-client-boot/ucc-1.0-rev3-desktop-image.img .

real 4m52.171s
user 1m48.268s
sys  1m5.204s

We could only reduce amount of data that has to copied during rollout if we would rsync the archiv (not the sparse image file) and decompress it on the client. But this takes to long with xz. tar could be an alternative, but the tar archives are slightly bigger than the xz archives.

-> tar Scvpzf ucc-1.0-rev3-desktop-image.img.tar \
ucc-1.0-rev3-desktop-image.img

-> du -h ucc-1.0-rev3-desktop-image.img.tar
3,7G ucc-1.0-rev3-desktop-image.img.tar

#  rsync the archiv on the UCC client, only 3.7G are copied, not 7,3
-> time rsync -a \
/var/lib/univention-client-boot/ucc-1.0-rev3-desktop-image.img.tar .
real 1m19.666s
user 0m27.772s
sys  0m16.420s

# extract archiv on the UCC client
-> time tar xzSpf ucc-1.0-rev3-desktop-image.img.tar
real 2m28.598s
user 1m15.952s
sys  0m40.240s

If we use a tar archiv the rollout of an UCC desktop image would copy 3.7GB instead of 7.3GB, with the downside of a bigger archiv file.

Not worth the effort right now.
Comment 2 Philipp Hahn univentionstaff 2023-06-28 10:30:27 CEST
UCC is EoL