Bonjour Ce n'est pas tordre le système de snapshot que de les garder longtemps ?
Pour lvm les snapshots sont en copy on write. Apparemment btrfs ferait pareil vu la description du comportement. Tout ce que j'ai lu dit que les snapshot sont des instantanés qui servent le temps d'un backup. Autrement dit : - on fige le FS sur le disque - on met à part les écritures (une sorte de tampon, et lvm ou le FS le gère selon le cas) -jusqu'à ce que le FS figé soit pleinement exploité pour une tâche de sauvegarde. - la tâche terminée, on détruit le snapshot en y incorporant les écritures précédemment mises à part (là encore lvm ou le FS gère cela) On peut tout aussi bien historiser les sauvegardes et laisser le backup les gérer (backuppc par exemple mais guère pour un usage pro sur grosse quantités de données) Le 2 mai 2017 17:46:40 GMT+02:00, Daniel Caillibaud <m...@lairdutemps.org> a écrit : >Le 21/03/17 à 11:42, Pierre Malard <p...@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 -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
