Bonjour,
Je suis entrain de découvrir btrfs. J'ai regardé un peu le fonctionnement des sous-volumes.
Je suis entrain de me demander du coup comment installer une machine avec btrfs. Vaut-il mieux avoir encore tout un tas de partition (par exemple uns pour / et une pour /home) ou une seule partition et un sous volume pour / et un autre pour /home ?
À coté de ça je sais que grub-pc n'aime pas encore btrfs donc je lui préparerais de toute manière une partition ext4.
Merci pour vos idée
# /run
Posté par err404 (site web personnel) . Évalué à -1.
Tu aura peut être besoin de /run, que ce soit dans à la racine ou à part...
https://linuxfr.org/news/run-or-not-run
Dans tous les cas, je sépare au moins le /home du reste, sauf si le disque dur est très petit.
[^] # Re: /run
Posté par barmic . Évalué à 4.
Je vois pas le rapport. Ce que je demande c'est est ce que les sous volumes btrfs sont fais pour être substitués aux partitions ou pas.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Des éléments de réponse
Posté par Zylabon . Évalué à 3.
Btrfs n'a pas encore de fsck, donc il est moins sûr que l'ext4
Les fonctionnalité de btrfs :
snapshot : Pour le /home, je ne vois pas le moindre intérêt, étant donné qu'on ne peut pas travailler fichier par fichier
compression : les gros fichiers sont déjà compressé (images, films), la compression est surtout efficace sur les binaires
Défragmentation : Les performances en lecture du /home présentent peu d’intérêt.
D'autre part, il est toujours moins performant que le l'ext4.
Son empreinte mémoire est plus importante que l'ext4.
De plus, pour pouvoir utilise la fonction snapshot, il ne faut surtout pas que le /home et le / soient dans le même sous-volume (ou une restauration du snapshot affectera le /home).
En revanche, pour le / il est possible de créer un sous-volume par répertoire et ainsi pouvoir les traiter indépendamment les uns des autres. Parce que par exemple faire un snapshot de /tmp ne présente pas le moindre intérêt. Ou parce que l'on peut vouloir restaurer un snapshot de toute la racine sauf /var, /home et /srv par exemple.
Please do not feed the trolls
[^] # Re: Des éléments de réponse
Posté par barmic . Évalué à 2.
C'est drôle je demande quel est la bonne manière pour l'utiliser et tu me réponds sur pourquoi je devrais m'en passer.
La fiabilité n'est pas vraiment un problème pour moi, je suis près à restaurer mon /home et/ou à appliquer mon clone sans problème.
Je suis d'accord que les snapshots de /home on peut d'intérêt pour moi. Mais bien intégrés à nautilus ça peut être intéressant comme remplacement d'une corbeille.
La compression, je m'en fiche un peu, mais les fichiers textes ne sont pas compressés alors qu'ils ont une entropie faible.
La défragmentation je m'en fou.
Pour la performance, je n'ai pas remarqué. Pour son empreinte mémoire non plus.
Pour le moment j'ai deux partitions physiques une pour / et une pour /home (j'en ai une pour /boot en ext4), j'ai pas cherché à créer de sous volume tout est donc dans le sous volume par défaut. /tmp est en mémoire vive chez moi donc il n'est pas concerné par les snapshots. Pour /var ça ne m’intéresse pas de le séparé car je suis sur un netbook et je n'héberge pas de serveur dessus.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Des éléments de réponse
Posté par Zylabon . Évalué à 2.
Oh ! Non surtout pas :) C'est génial le Btrfs ! il faut absolument l'utiliser !
Pour l'empreinte mémoire, j'aurais dû préciser, certe l'empreinte mémoire du btrfs est plus élevée que l'ext4, mais je parlait de l'empreinte mémoire sur le disque qui est significativement plus importante. un petit test vite fait, sur une partition en ext4, si je la sature avec un fichier de zero, il fait 572Mo, sur la même partition formatée en btrfs, il fait 500Mo. Sur une partition si petite c'est très significatif, évidement c'est moins sensible avec des grosses partition, mais l'espace disque consommer par btrfs n'est pas négligeable.
Please do not feed the trolls
[^] # Re: Des éléments de réponse
Posté par barmic . Évalué à 2.
Et si tu active la compression ? Bien sûr sur un fichier de 0 le test deviens biaisé, mais si cette option ne le contrebalance pas ce problème il doit en limiter la gène.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Des éléments de réponse
Posté par Zylabon . Évalué à 2.
En activant la compression le seul chiffre à la louche que j'ai, c'est que j'ai gagné 50% de place sur la racine (sans le /home), avec l'algo zlib, celui par défaut.
Et effectivement, avec le fichiers de 0 les dés sont pipés. Quoi qu'un fichier de 700Mo occupe quand même 24Mo (la relation est linéaire d'après mes tests).
Et oui, carrément, mon installation de Fedora c'est 5Go sans compression, 2.5Go une fois qu'elle est activée.
Please do not feed the trolls
[^] # Re: Des éléments de réponse
Posté par barmic . Évalué à 2.
C'est très intéressant ça ! Je sais pas si le gain est supérieur avec lzo. La seule chose à la quelle il faut faire gaffe avec ça c'est lors que l'on backup les données sur un disque externe par exemple avec un autre système de fichier.
Ça peut s'activer après coup ? À chaud ? Ça consomme beaucoup de ressources pendant la « conversion » ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Des éléments de réponse
Posté par Zylabon . Évalué à 1.
Pour l'activer, il suffit de remonter le volume avec l'option compress ou compress=lzo, la compression est activée, mais les fichiers déjà présents sont pas affecté. On peut ensuite reconstruire le système de fichier avec la nouvelle option avec
btrfs filesystem balance
ça prend quelques secondes/minutes, et en terme de consommation en ressource, tout ce passe en espace noyau donc c'est dur à suivre, mais ça a l'air assez léger. Ça empêche pas de faire des truc à coté.
Alors, sur mon Arch : J'ai juste changé l'option de montage dans le fstab pour compress=lzo (sans régénérer l'initram)
avant : 2.6Go
(6 minutes de régénération, principalement limitée par l'accès au disque)
Après : 2.7Go
Je viens de lire que l’intérêt du lzo était sa vitesse, avec un taux de compression plus faible.
(et le backup c'est pour les fillettes :p)
Le Btrfs c'est vraiment trop cool, plus simple c'est pas possible.
Please do not feed the trolls
[^] # Re: Des éléments de réponse
Posté par patrick_g (site web personnel) . Évalué à 3.
C'était déjà signalé sur la dépêche du noyau 2.6.38 dans le paragraphe sur btrfs.
Espèce de mécréant ! ça veut dire que tu ne lis pas les news LinuxFR ? Au bucher !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.