Le 21/03/17 à 11:42, Pierre Malard <[email protected]> a écrit : PM> J’ai lu que BtrFS semblait se présenter comme le « successeur » de ext4 et proposait un PM> redimensionnement à chaud en complément du gestionnaire de volumes logiques de Linux. Il PM> permettrait également l’agrégat de préifériques et la gestion de « snapshots PM> » (https://fr.wikipedia.org/wiki/Btrfs). Avez-vous une expérience dans ce domaine et est-ce PM> que cela répondrait à notre besoin de gros volumes extensibles ?
J'arrive longtemps après la question, au cas où ça serve à d'autres… Je n'ai pas d'expérience de btrfs sur de tels volumes, mais sur 3~4To de datas avec bcp de snapshots, il faut faire attention à l'ordre des snaphots pour garder une "filiation la plus linéaire possible". C'était pour du backup, je faisais - rsync de pleins de vm dans last (un subvolume) - delete Monday && snapshot de last sur Monday le lundi - … idem les autres jours, avec en plus le dimanche un - delete week_XX && snapshot de last sur week_XX mais de temps en temps, et de plus en plus souvent avec l'augmentation du nb de snapshots, le delete faisait complètement exploser le système, à retardement (lorsque btrfs nettoie ses metadatas, un peu plus tard, si le rsync démarre avant que tout soit nettoyé). L'explosion se traduisait par un système qui fige, avec ou sans oomkill tous azimuts. Un expert btrfs m'a confirmé avoir déjà vu la RAM exploser dans ce genre de cas, sans vraiment savoir pourquoi… (que le load explose parce que le fs devient très lent ça peut s'expliquer, mais pas qu'il consomme énormément de RAM). C'est visiblement lié au fait du nb de snapshots qui dépendaient du volume dans lequel j'écrivais, chaque écriture sur un fichier déclenchant une cascade d'opérations pour que tous les subvolumes retrouvent leurs petits (tous ses snapshots doivent se mettre à jour sur l'ancienne version du fichier, trouver lequel la détient, etc.) En modifiant la rotation pour faire mv Monday avirer mv last Monday snapshot Monday last rsync vers last ça va bcp mieux (chaque écriture ne déclenche qu'un seul copy on write sur le dernier snapshot sans que les autres n'aient à faire qqchose, la suppression d'un subvolume n'entraînant de modif que chez son unique "fils"). Tout ça pour dire que btrfs reste chatouilleux et peut partir en vrille (machine HS mais pas perdu d'octet), même si la gestion des snapshots reste un avantage très appréciable. Et je n'ai pas encore osé passer au btrfs send/receive pour synchroniser deux volumes, mais chez d'autres ça marche vraiment très bien (10~100 × plus rapide que rsync suivant le nb de fichiers, le volume et la BP dispo). -- Daniel On devrait construire les villes a la campagne car l'air y est plus pur ! Alphonse Allais
