Aymeric / APLUFR @aplufr@mastodon.tetaneutral.net

@sebsauvage @Lapineige Tel que la phrase est tournée dans la doc pour moi ça ne concerne que certaines branches / kernel et en 5.10 on n’est plus affecté.
Et là ça n’a pas fait sauter complètement la dedup... juste sur 2/3 des fichiers entre 3 snapshots.

@Lapineige @sebsauvage j’ai un peu investigué, pour une raison qui m'échappe la defrag a fait sauter partiellement la dedup sur un snapshot.
J’ai : A, B et C
B est un snapshot de A, C est un snapshot de B.
A part quelques fichiers en plus, ces 3 dossiers sont strictement identique sur grosso modo 1.5To de données.
Hors depuis la defrag pour passer en zstd, il y'a environ 500Go de données qui ne sont plus dedup entre ces 3 sous volumes...

@Lapineige Mon setup , c’est parce que je veux être sur que la machine boot en réseau, y compris si il manque un disque dur et le volume btrfs est monté à la main quand c’est up.
Et que mdadm/ext4 je sais que ça boot même avec un seul disque (déjà testé) alors que btrfs faut du "recovery/degraded" pour qu'il boot.

Au final le système n’est pas super critique dans mon cas, à part le fichier /etc/exports :)

@Lapineige Avec un chattr sur un dossier tu peux désactiver CoW / compress oui mais c’est tout.

Les profiles raid1/single/etc ne sont pas possible pour des sous volumes, c’est forcement tout le volume btrfs qui se comporte pareil (y compris des volumes parents du volume monté).

Chez moi, j’ai un setup particulier, mon système et /tmp sont sur un ext4 en raid1 sur 2 disques et le btrfs est utilisé pour stocker des données en mode nas sur les autres disques :)

@Lapineige Yep, j’ai relancé une dedup complète.. avec duperemove.
Pour le plus de fichier/blocks comprimé par zstd, je pense que zstd certains de mes fichiers que zlib ET il me semble que j’avais activé la compression avec un kernel 4.19 maintenant je suis en 5.10 (donc probablement meilleur algo pour estimer si c’est utile ou pas).

@sebsauvage

@Lapineige même en changeant la compression à la main à coup de `defrag -c`, ça ne concernera que les fichiers qui sont vu par le defrag pas les nouveaux qui agiront toujours selon ce que tu as dans l'option de mount.

Le truc que j’aimerai avec btrfs c’est pouvoir avoir des subvolumes en raid1 et d'autres en single, la compression je m’en fous d’avoir la même partout.

Pour /tmp, tmpfs (en ram du coup) ?

@Lapineige @sebsauvage pourtant promis c’est le même volume btrfs.
Les données "referenced" sont quasi identique sur les des deux (j’ai supprimé quelques trucs…).
Il y'a plus de données en volume qui ont été comprimé par zstd mais je pense que ça a fait sauté de la dedup sur certains fichiers (j’ai un deux snapshots de 1.5To), du coup le "uncompressed" a augmenté .. et avec un peu le disk usage du coup.

@sebsauvage @Lapineige

Du coup après conversion de zlib vers zstd ici ça donne.. donc plus (+) de fichier sont comprimés mais l'espace total sur le disque a un peu augmenté (mais c’est peut être des fichiers qui avait de la dedup qui ne le sont plus), j’ai viré quelques snapshots pendant la manip aussi.

@Lapineige https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs(5)#MOUNT_OPTIONS

Note: most mount options apply to the whole filesystem and only options in the first mounted subvolume will take effect. This is due to lack of implementation and may change in the future. This means that (for example) you can’t set per-subvolume nodatacow, nodatasum, or compress using mount options. This should eventually be fixed, but it has proved to be difficult to implement correctly within the Linux VFS framework.

@Lapineige Je viens de lire ton billet, la dernière phrase me perturbe.
« Personnellement j’ai mis mes archives en ztsd 4, mes dossiers courants en zstd 2.»

C’est plusieurs volumes physiques btrfs distinct ou des sous volumes ?
Si sous volumes, il me semble que le niveau de compression est le même pour tous, même si tu changes les options de mount.

@Lapineige @sebsauvage je pourrais tenter de changer l'algo de compression pour avoir des stats entre les 3, mais avec le volume de donnée ça va prendre 3 plombe 😅

@Lapineige @sebsauvage
Pour la dedup :

btrfs fi du -s .
Total Exclusive Set shared Filename
8.67TiB 4.04TiB 1.16TiB .

@Lapineige @sebsauvage pour la dedup sur des photos, même si tu prends 2 photos de la même chose à 1ms entre les deux, ça ne se comprimera pas. la dédup par block c’est par morceau de 32ko, 64 ou 128 (tu peux choisir avec dedup) et en photo c’est comme avec l'audio, t'as toujours un bit qui change par si par là.

La seule chose que tu vas vraiment dedup c’est l’header jpeg

@Lapineige @sebsauvage y'a literalement de tout... les vidéos brut et pas du tout compressible (rawvideo de mes captures vhs), des VMs, des photos, des ISOs, ...

@Lapineige @sebsauvage
Euh zlib parce que c’est l’algo qui comprime le plus et que le temps cpu c’est pas mon soucis.. et d’ailleurs j’ai pas d’algo spécifié dans les options de mount… j’avais du faire un truc forcé un jour ^^

Pre-alloc ça doit être un fichier vide que j’ai crée qui reserve la place sur disque mais qui ne contient pas de donnée (avec tu fais ça avec falloc).

@Lapineige @sebsauvage non qui indique la même chose mais avec des valeurs différentes. Genre volume size 8T = 16T, usage : 5T= 10T etc (les magies liée au raid1).

Je lance du btrfs fi du pour te répondre sur la dedup ;)

@Lapineige @sebsauvage

Hum, ici c’est surtout la dedup, j’ai pas mal de donnée non compressible :)

Plutôt fun d’ailleurs, on a plein valeurs identiques entre df, compsize, et btrfs fi usage qui pourtant indiques la même chose 😂