Journal ZRAM et ZSWAP et les mythes associés

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
31
28
mar.
2026

Chris Down, développeur sur le sous-système mémoire du noyau linux, a publié un article qui fait le point sur zram et zswap et quand utiliser l'un ou l'autre :
https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html

zram et zswap sont des mécanismes noyau permettant de compresser une partie de la mémoire vive soit en remplacement du swap disque (zram), soit en stockage entre la mémoire et le disque (zswap).

en résumé :

  • Zram utile quand on n'a pas de swap sur disque (rotatif ou ssd), couplé (…)

Forum Linux.débutant Question sur la gestion des fichiers compressés avec gzip sous Linux

Posté par  . Licence CC By‑SA.
Étiquettes :
4
22
sept.
2024

Bonjour à tous,

Je suis en train de gérer une grande quantité de fichiers sur mon serveur, et je cherche des astuces pour optimiser la compression et la décompression avec la commande gzip sous Linux. J'ai lu quelques articles qui mentionnent l'impact de certaines options de gzip sur la taille des fichiers et la vitesse de traitement, mais je me demande si vous auriez des recommandations pratiques en fonction de vos expériences.

Par exemple, quelles sont les options que vous (…)

Journal zpaq : backup incrémental avec déduplication

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
45
2
mai
2016

Je m'intéressait aux techniques de déduplication quand je suis tombé sur cette petite perle.
http://mattmahoney.net/dc/zpaq.html

Un petit outil en ligne de commande qui n'a l'air de rien, écrit par un expert à la retraite dont c'est le passe temps entre deux courses d'ultrarunning…

La déduplication c'est quand on essaye de retrouver des bouts de fichiers communs pour éviter de les stocker à nouveau. zpaq permet de gérer la déduplication au sein de chaque fichier mais également entre les fichiers. Si (…)

Forum général.général Recompresser un son (ou une image) venant d'une compression avec perte

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
0
7
fév.
2016

Bonjour,

Aujourd'hui, je viens vous demander votre avis après une recherche infructueuse sur ce sujet.

On sait qu'il vaut mieux, si on peut, ne pas compresser avec perte un flux audio (ou vidéo, d'ailleurs) qui a déjà déjà été compressé avec perte (par exemple PCM original → OGG Vorbis → MP3) : à chaque étape, on altère l'information.

Dans le cas qu'il me questionne, on est en possession d'un flux audio PCM (disons, un CD audio) dont l'origine est une (…)

FLIF, un format d’image sans perte, intelligent et « performant », sous licence GPL

Posté par  . Édité par Davy Defaud, Benoit Sibaud, palm123, claudex et bubar🦥. Modéré par tuiu pol. Licence CC By‑SA.
Étiquettes :
64
4
oct.
2015
Technologie

Pendant que les technologies en termes de compression vidéo continuent d’avancer, on attend toujours la relève en termes de compression d’images. JPEG2000, PNG et GIF sont des formats qui commencent à prendre de l’âge, et chaque format a sa cible d’utilisation. Peut‐être plus pour longtemps, un nouveau format entre dans l’arène, il est libre et répond au doux nom de FLIF.

Journal Algo de compression JPEG waifu2x

Posté par  . Licence CC By‑SA.
Étiquettes :
14
23
mai
2015

Salut les moules qui font du graphisme ou qui aiment les Anime.

Je suis tombé sur une info qui je l'espère pourra intéresser certains (d'où ce journal, parce que perso, je m'en bat le coquillart).

Disclaimer: Je ne m'y connais pas du tout dans le domaine. Mon coquillart non plus.

Il s'agit d'un algo pour compresser en JPEG, qui serait apparemment spécifiquement pensé pour mieux gérer les images issues du monde de l'Anime.

Ci-dessous l'exemple donné sur le github du (…)

Revue de presse de l'April pour la semaine 4 de l'année 2015

Posté par  (site web personnel, Mastodon) . Modéré par Nÿco. Licence CC By‑SA.
Étiquettes :
22
27
jan.
2015
Internet

La revue de presse de l'April est régulièrement éditée par les membres de l'association. Elle couvre l'actualité de la presse en ligne, liée au logiciel libre. Il s'agit donc d'une sélection d'articles de presse et non de prises de position de l'association de promotion et de défense du logiciel libre.

Sommaire

Journal 2 vulnérabilités découvertes dans LZ0 et LZ4

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
21
30
juin
2014

Les vulnérabilités découvertes pour LZ0 et pour LZ4 viennent d'un code datant de 1999.

En résumé, elles provoquent un dépassement du tas d'entier non-signé, ce qui conduit à une corruption locale de la mémoire.

Ce bogue n'est pas super pratique à utiliser, car il faut lancer la fonction incriminée avec assez de données pour dépasser la limite d'un entier non signé, ce qui dépend donc de l'architecture.

En pratique, cela signifie qu'une architecture 64 bits est plutôt à l'abri.

Le (…)

Les nouvelles versions du noyau seront publiées en .xz

Posté par  . Édité par Benoit Sibaud, ariasuni, Ontologia et Florent Zara. Modéré par Bruno Michel. Licence CC By‑SA.
Étiquettes :
24
31
déc.
2013
Noyau

La vieille blague de linuxfr.org IPOT prédisait que le noyau 3.2.24 ne serait plus publié au format bz2, rendant la décompression de l'archive impossible avec les moyens de 2001. Cela fait un moment que les noyaux sont publiés en tar.gz, tar.bz2 et tar.xz, on apprend maintenant que les prochaines versions du noyau seront publiées uniquement en tar.gz et tar.xz. La prochaine révision longterm 3.2.54 sera donc l'une des toutes premières affectées, la différence étant d'un seul caractère avec la prédiction d'IPOT.

Plus sérieusement, je me demande quelles options de compression seront utilisées. En effet dans le cas de la compression .xz, les besoins en mémoire augmentent considérablement pour les niveaux compressions les plus élevés (source man xz) :

(traduction) « L'utilisation de mémoire avec xz varie de quelques kilooctets à plusieurs gigaoctets, en fonction de paramètres de compressions. […] Le décompresseur aura typiquement besoin de 5% à 20% de la mémoire nécessaire au compresseur pour créer le fichier. […] Cependant, il arrive que des fichiers .xz requièrent plusieurs gigaoctets de mémoire pour être décompressés. »

(texte original) « The memory usage of xz varies from a few hundred kilobytes to several gigabytes depending on the compression settings. […] Typically the decompressor needs 5 % to 20 % of the amount of memory that the compressor needed when creating the file. […] Still, it is possible to have .xz files that require several gigabytes of memory to decompress. »

NdM : merci à JGO pour son journal.