Re: Gestion de très gros FS
Le 21/03/17 à 11:42, Pierre Malard <plm@teledetection.fr> 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
Reply to: