À qui n'est-ce pas arrivé, quand on présente des fonctionnalités avancées aussi abstraites que des «snapshots inscriptibles dans Btrfs», de se demande à qui ça pourrait servir ?
En effet, quand on entend ce genre de choses, on a tendance à dire que ça ne servira que dans des fermes de serveurs virtualisés, ou je ne sais quoi.
Petit rappel : Btrfs est un nouveau système de fichier pour le noyau Linux, encore en développement. Outre sa manière bien spéciale de stocker les fichiers sur le disque (sous forme de B-tree), il permet également tout un tas de fonctionnalités toutes plus farfelues les unes que les autres, comme le redimensionnement à chaud, la défragmentation à chaud, les snapshots, etc.
Un snapshot est une image de l'état dans lequel se trouve le système de fichier à un instant T. On peut le voir comme une révision dans les systèmes de contrôle de révisions. Par exemple, imaginez que vous avez un certain système de fichiers, et que vous allez y apporter des modifications. Pour ne pas perdre de données, vous allez créer un snapshot contenant l'état actuel, et le supprimer si tout s'est bien passé.
C'est justement ce fonctionnement qui m'a donné une idée d'application dans la vie de tous les jours de ces snapshots inscriptibles :
Madame Michu découvre la console. Elle n'est pas du tout à l'aise, et suit un tutoriel trouvé quelque-part. Elle n'a vraiment pas confiance. Pour travailler en sécurité, elle commence par taper la commande "snapshot", par exemple. Cette commande, un script shell, crée un nouveau snapshot (éventuellement nommé suivant la date et l'heure, et enregistré quelque-part).
Ensuite, elle fait ses modifications. Une fois les modifications terminées, soit tout a bien marché, et elle tape "apply", soit quelque-chose a mal tourné, et elle tape "revert".
Madame Michu est donc contente, car elle peut faire ce qu'elle veut, y compris un "rm -rf /" (bon, peut-être pas, /usr/bin/revert doit exister, sauf si c'est une commande interne de son shell), si quelque-chose tourne mal, un simple revert lui remettra son système de fichier exactement comme il était.
Un autre cas : Monsieur Michu (qui a entre temps pu avoir accès à l'ordinateur) décide d'installer un paquet. Son gestionnaire de paquets, en toute transparence, lui crée un snapshot. Ensuite, il installe les paquets. Si quelque-chose tourne mal, et que le système a été touché, un revert suffira à le remettre d'aplomb. Si tout va bien, on continue.
Autre cas, la fameuse «restauration système» de Windows. Monsieur Michu va installer une application en la compilation lui-même, pour la première fois. Il est un peu plus frileux que Madame Michu, et donc suit scrupuleusement la documentation, qui ne précise pas la suite «snapshot, revert». Par contre, prudent, il va dans la GUI «Restauration du système», et crée un nouveau point de restauration. Il peut alors s'amuser comme il veut, modifier tout son système, puis finalement restaurer son point si quelque-chose a mal tourné. Remarquez que l'application de restauration étant en RAM, un "rm -rf /" peut être contré !
Encore un autre cas ! Madame Michu, qui s'est battue avec son mari pour récupérer l'ordinateur (avant qu'il ne soit totalement foutu), décide de modifier un document OpenDocument pour son travail. Elle sait qu'elle va y apporter de grosses modifications, et n'a pas envie d'en créer des copies. Clic droit»Propriétés»Historique»Créer un point de sauvegarde, et le voilà placé dans son "petit snapshot" (note: il faut voir si c'est possible de versionner tout un fichier et pas seulement un disque entier, pour permettre de restaurer les fichiers un à un).
Elle modifie ensuite son fichier, puis l'enregistre. Elle peut faire ça plusieurs fois, l'onglet «Historique» lui affiche toutes les versions, c'est parfait. Si un jour elle fait une bêtise, un simple revert lui rendra le sourire.
Voilà, ceci est la liste de tout ce qu'on peut imaginer avec ce magnifique Btrfs. Inutile maintenant de vous dire que ce sera le système de fichiers par défaut de Logram, une fois sorti (mais à mon avis, Logram sortira après Btrfs).
Petits points intéressants :
- Btrfs est censé capturer des snapshots instantanément
- Dans mes exemples, les snapshots ne doivent pas être inscriptibles. On pourrait tourner ça de la sorte : créer le snapshot » passer dedans » écrire dedans » le garder ou le jeter
- Il faut voir s'il est facile de passer un snapshot comme étant la «racine du système de fichier», c'est à dire ce que fait la commande «apply». Btrfs étant en développement, on pourrait le demander à ses développeurs
Voilà, j'attends vos avis. Avez-vous d'autres idées ? Trouvez-vous ceci intéressant ? Est-ce possible techniquement (maintenant ou plus tard) ?
# Au niveau de l'existant
Posté par psychoslave__ (site web personnel) . Évalué à 6.
[^] # Re: Au niveau de l'existant
Posté par steckdenis (site web personnel) . Évalué à 5.
Mais ce dont moi je parle, c'est aussi une intégration avec KDE. Mais sinon, vraiment pas mal. J'aime bien l'interface (qui occupe un peu trop de place à l'écran à mon gout).
Je sens que ça va finir par une libatomicalfilesystem dans Logram, pour pouvoir utiliser ce genre de fonctionnalités avec Btrfs, ZFS et autres systèmes de fichiers le supportant.
Merci beaucoup pour le lien, et mes félicitations aux développeurs.
[^] # Re: Au niveau de l'existant
Posté par Nico C. . Évalué à 9.
Mais ca montre un point absolument alarmant actuellement : l'integration quasi nulle des systemes de fichiers dans les desktop managers.
Quand on voit que meme les ACL ne sont pas gerees par Gnome (et KDE ?), quand vont etre integrees les fonctionnalites hyper avancees et nombreuses de btrfs ???
A quoi ca sert d'avoir 25 FS a disposition si y'en a pas un seul (meme ext3 !!) qui n'est supporte un minimum par les DM ?
[^] # Re: Au niveau de l'existant
Posté par zebra3 . Évalué à 10.
Installe le logiciel Eiciel, et tu pourras modifier tes ACLs avec Nautilus, dans les propriétés des fichiers. Hé oué, GNOME n'est pas si pourri, à condition d'utiliser les bons logiciels.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Au niveau de l'existant
Posté par liberforce (site web personnel) . Évalué à 2.
[^] # Re: Au niveau de l'existant
Posté par Pinaraf . Évalué à 4.
Sinon une difficulté pour les environnements, c'est qu'ils ne tournent pas que sous Linux mais aussi sur les systèmes BSD par exemple. Donc faut faire des abstractions, c'est pas forcément évident, ça prend du temps...
[^] # Re: Au niveau de l'existant
Posté par Mildred (site web personnel) . Évalué à 1.
Parce qu'a ce moment là, les BSD devraient aussi pouvoir l'implémenter, non?
[^] # Re: Au niveau de l'existant
Posté par Pinaraf . Évalué à 1.
Par contre une fonctionnalité comme les snapshots, non.
Puis KDE tourne sur autre chose que les UNIX...
[^] # Re: Au niveau de l'existant
Posté par gaaaaaAab . Évalué à -1.
ça doit être parce que ça sert à rien. Franchement, les ACL ... qui a *vraiment* envie de passer du temps à définir des droits d'accès super fins ?
Du temps ou j'utilisais Windows en réseau (c'était en école d'ingé y'a quelques années), c'était d'un pénible ... (en même temps, avec une GUI, c'est un peu couru d'avance)
sinon, ça doit aussi être parce que seuls quelques FSs gèrent des ACLs, et en plus, ils gèrent pas tous les même ...
[^] # Re: Au niveau de l'existant
Posté par pasBill pasGates . Évalué à 9.
Qui a envie ? C'est pas qui a envie, c'est qui a besoin.
Tu fais comment sous Unix pour donner des droits a 3 ou 4 utilisateurs differents sans creer un groupe ? Ah ben ouais, tu peux pas, et donc sans etre root tu es dans la merde parce que tu peux pas creer de groupe sans etre root (tu peux sudo groupadd mais ca serait une faille enorme car un user standard pourrait forcer un groupe avec le meme GID qu'un groupe systeme...)
[^] # Re: Au niveau de l'existant
Posté par briaeros007 . Évalué à 2.
-> le rajouter à un groupe (qui peut avoir à d'autres dossiers/fichiers)
-> modifier le groupe du fichier (ce qui peut bloquer d'autres utilisateurs)
[^] # Re: Au niveau de l'existant
Posté par gaaaaaAab . Évalué à 4.
Dans un contexte professionel, il me semble que des groupes pré définis par l'admin sys devrait répondre au besoin. Pour les données professionnelles, la rétention d'information n'est pas vraiment indiquée, et pour les données personnelles de l'employé, des droits limités à l'utilisateur permettent de garantir leur confidentialité.
Reste le cas des données personnelles à partager avec seulement quelques collègues mais est-ce vraiment le rôle d'un service d'infrastructure de se préoccuper de ça ?
En fait, dire que les ACLs fins permettent à l'utilisateur de gérer finement les droits sur ces fichiers, ça ne répond pas vraiment à la question. Au delà de l'utilité immédiate (donner des droits sans créer de groupes), ça s'inscrit dans quel contexte, dans quelle perspective. Bref : ça sert à quoi ?
[^] # Re: Au niveau de l'existant
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
Tu as donc besoin de de deux groupes, donc les ACLs. Tu pourrais mettre les droits "etienne:webdev 0775", mais le problème c'est que tu veux que ww-data puisse écrire dans certain répertoire, donc tu va faire un "etienne:www-data 0770" et mettre une ACI qui va donner à "webdev" les droits rwx.
C'est une utilisation que j'ai et je crois que ça répond à ta question.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Au niveau de l'existant
Posté par psychoslave__ (site web personnel) . Évalué à 3.
[^] # Re: Au niveau de l'existant
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: Au niveau de l'existant
Posté par psychoslave__ (site web personnel) . Évalué à 3.
Sinon UDF + ACL aurait été le candidat idéal voir https://linuxfr.org//~alenvers/28585.html
[^] # Re: Au niveau de l'existant
Posté par pasBill pasGates . Évalué à 1.
https://linuxfr.org//comments/1052497.html#1052497
Alors, la règle c'est d'avoir des secteurs de taille égale aux blocs du périphérique sous-jacent. Donc 512 sur la plupart des clefs USB.
C'était donc :
- un truc à ne pas oublier : demander à mkudffs de créer un SF avec secteurs de la bonne taille ;
- un bogue du noyau Linux <= 2.6.26, qui montait systématiquement avec taille de secteurs de 2048, sauf option contraire explicite.
Windows supportait correctement UDF sur peripheriques de masse avant Linux
[^] # Re: Au niveau de l'existant
Posté par psychoslave__ (site web personnel) . Évalué à 3.
Donc, je vois mal microsoft sortir un patch de support d'UDF pour Xp. Or, le but c'est quand même d'avoir un truc utilisable partout, autre que fat et ntfs. Je ne connais pas les stats, mais Xp représente encore certainement une sacré partie du parc, donc UDF.
Bon c'est bien que ce soit géré dans les nouvelles versions, mais quand on croise encore des postes équipés de win98 par ci par là, je me dit qu'UDF comme solution qu'on est sûr de pouvoir utiliser partout, c'est pas pour demain.
[^] # Re: Au niveau de l'existant
Posté par pasBill pasGates . Évalué à 1.
Super, et pour les Linux n'ayant pas le kernel 2.6.26 ou plus, tu fais quoi ?
Parce que bon, XP c'etait les kernel 2.4 hein, et il n'y a plus aucune distrib qui supporte ca quasiment...
Bon c'est bien que ce soit géré dans les nouvelles versions, mais quand on croise encore des postes équipés de win98 par ci par là, je me dit qu'UDF comme solution qu'on est sûr de pouvoir utiliser partout, c'est pas pour demain.
Tout a fait, ca ne veut pas dire que la faute en revient a MS pour autant.
[^] # Re: Au niveau de l'existant
Posté par Albert_ . Évalué à 5.
Tu upgrades? Ca coute pas cher et de plus le matos anciens est toujours supportes. Deux petits details qui ne sont plus vrai avec les systemes d'exploitation de Microsoft.
[^] # Re: Au niveau de l'existant
Posté par pasBill pasGates . Évalué à 0.
[^] # Re: Au niveau de l'existant
Posté par Pinaraf . Évalué à 2.
[^] # Re: Au niveau de l'existant
Posté par psychoslave__ (site web personnel) . Évalué à 3.
Pour ce qui est de la faute de microsoft, si ils pétaient pas les burnes avec des brevets logiciels, ntfs me conviendrais tout aussi bien qu'UDF.
[^] # Re: Au niveau de l'existant
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Au niveau de l'existant
Posté par psychoslave__ (site web personnel) . Évalué à 3.
Autre contrainte éventuel, pas de limitation trop contraignante au niveau de la taille des fichiers, adieu fat.
Enfin le but ici est de trouver un FS exempt de toute menace jurdique, donc adieu NTFS.
Au final, aujourd'hui on a rien qui répond à toutes ces contraintes.
[^] # Re: Au niveau de l'existant
Posté par pasBill pasGates . Évalué à 0.
Bref, inutile de pointer le doigt sur MS, parce que Linux ne resoud pas le probleme de son cote non plus, dans les 2 cas il faut une update pour la majorite des machines, que ce soit un driver ajoute ou un kernel plus frais.
[^] # Re: Au niveau de l'existant
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Au niveau de l'existant
Posté par barmic . Évalué à 2.
Mais il y a des serveur qui mettent pas à jour leur noyau, donc tu ne va pas pouvoir brancher ta clef sur certains serveur ça s'est une grosse contrainte...
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Au niveau de l'existant
Posté par briaeros007 . Évalué à 2.
Euh brancher une clée usb sur un serveur... y'a que moi que ça fait tiquer ?
[^] # Re: Au niveau de l'existant
Posté par barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Au niveau de l'existant
Posté par briaeros007 . Évalué à 2.
[^] # Re: Au niveau de l'existant
Posté par Psychofox (Mastodon) . Évalué à 1.
Au final, aujourd'hui on a rien qui répond à toutes ces contraintes.
Faut arrêter aussi avec la mauvaise foi.
Les brevets ne s'appliquant pas par chez nous, je ne vois pas pas ce que tu en as à foutre. Si ça te démange tant que ça, arrête de partager tes fichiers avec des gens utilisant un OS sale.
[^] # Re: Au niveau de l'existant
Posté par psychoslave__ (site web personnel) . Évalué à 4.
[^] # Re: Au niveau de l'existant
Posté par Psychofox (Mastodon) . Évalué à 2.
Le méchant dans cette affaire, c'est la loi américaine et leur office des brevets, pas microsoft.
Reste que pour ton usage personnel, tu n'en as juste rien à battre et microsoft n'a aucun devoir de fournir un support d'autres filesystems.
[^] # Re: Au niveau de l'existant
Posté par briaeros007 . Évalué à 2.
Tomtom, qui n'est pas une boite américaine, a eux quelques problèmes avec ces brevets...
"tant que c'est bon pour moi, les autres ils ont qu'a aller se faire foutre" , c'est ce que tu essaie de nous dire ?
[^] # Re: Au niveau de l'existant
Posté par Psychofox (Mastodon) . Évalué à 2.
D'autre part, c'est hors sujet : on parle du choix d'un FS pour un utilisateur windowsphile. Si microsoft ne veut pas fournir le support pour ext3 ou autre fs utilisé sous linux, c'est leur droit et ça les regarde. Si les fat et ntfs leur suffisent, tant mieux pour eux. Si ça te dérange, tant pis pour ta gueule, t'as qu'à pas vouloir pénétrer des windows avec ton stick usb espèce de pervers.
[^] # Re: Au niveau de l'existant
Posté par gaaaaaAab . Évalué à 4.
ok, ça servirait moins à rien si c'était plus utilisable. Aujourd'hui (mon avis personnel que je partage), le niveau de complexité côté utilisateur pour la gestion fine des ACLs par rapport à l'intérêt que ça a n'est pas rentable.
c'est vrai que ça fait longtemps que je ne me suis pas penché sur le sujet (pas assez parano ? ;) du coup, ça a peut-être évolué mais je n'y crois pas trop.
[^] # Re: Au niveau de l'existant
Posté par mornik . Évalué à 3.
Mais je ne veux pas que ma copine puisse faire de même avec le reste des fichiers de mon /home (j'ai un backup de la mort pour les photos, pas forcément pour tout mon travail en cours).
Je mets donc un acl spécifique pour QU'ELLE puisse faire tout ce qu'elle veux avec mes photos, et rien d'autre dans mon home.
Ainsi je touche pas aux groupes et je cr&é pas un groupe moietmacherie pour juste gérer un répertoire photo.
C'est aussi ça l'intérêt
[^] # Re: Au niveau de l'existant
Posté par briaeros007 . Évalué à 3.
Quand il n'y a que deux personnes ca va encore :P
[^] # Re: Au niveau de l'existant
Posté par 2PetitsVerres . Évalué à 10.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Au niveau de l'existant
Posté par ckyl . Évalué à 2.
setfacl -d --set u::rwx,u:brittany:rwx::- PhotosEt c'est magique, tout les fichiers hériterons des bonnes permission automatiquement.
Peu de monde à besoin de définir des ACL compliquées, par contre il y a beaucoup d'use case ou les ACL rendent facile quelque chose qui était très chiant à faire ou pas possible avec les droits UNIX.
[^] # Re: Au niveau de l'existant
Posté par windu.2b . Évalué à 2.
[^] # Re: Au niveau de l'existant
Posté par ckyl . Évalué à 2.
Tu as un mécanisme beaucoup plus puissant que l'umask. Quand un objet est créé il peut hériter automatiquement des permissions de son parent. C'est beaucoup plus pratique qu'un umask, qui lui s'applique à ton uid. En général tu veux définir une politique d'accès pour un fichier ou pour un sous arbre. Pas pour tout les fichiers que tu créés.
Le modèle UNIX est assez limité et exige d'énormes contorsions dès que tu veux élargir ou restreindre l'accès à plusieurs personnes. Entre un umask associé à l'uid, la manipulation de groupes qui demande d'être root, de ne pas pouvoir hériter des permissions du répertoire parent, de ne pas avoir de mask. Marrant, je me souviens de la même discussion en 2004...
[^] # Re: Au niveau de l'existant
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Au niveau de l'existant
Posté par Albert_ . Évalué à -1.
[^] # Re: Au niveau de l'existant
Posté par ckyl . Évalué à 2.
Faire la même chose avec des ACL, ca ne demande pas de privilège particulier, et une unique action. Une fois que ta règle par défaut a été ajoutée t'es tranquille et ca n'a aucune incidence sur les autres fichiers. Tu peux facilement proposer une interface graphique très simple proposant "Partager tout les fichiers créés dans ce répertoire avec les utilisateurs suivants". Chose impossible avec les droits UNIX. Pourtant ça me semble être ce que veulent faire les gens en pratique...
Tout ce que tu dis c'est que les interfaces graphiques sont merdiques. Rien de nouveau sous le soleil. La première utilisation des ACL que j'ai eu, c'était pour partager les répertoires Video et Music de chaque compte entre tout les membres de la famille en 2002. Comme tu le vois un use case d'entreprise avec une sécurité militaire loin des besoins de madame michu. J'attends ta proposition pour une solution aussi simple avec les droits UNIX...
[^] # Re: Au niveau de l'existant
Posté par Albert_ . Évalué à 0.
[^] # Re: Au niveau de l'existant
Posté par Thomas Douillard . Évalué à 2.
Ça réponds à des besoins simples, facilement compréhensibles et explicables, sans exploiter toutes la puissance des ACL, mais on s'en fout un peu complètement, enfin madame Michu surtout.
[^] # Re: Au niveau de l'existant
Posté par briaeros007 . Évalué à 2.
setgid sur le répertoire racine, une seule foi.
Normalement ça marche.
[^] # Re: Au niveau de l'existant
Posté par bubar🦥 (site web personnel) . Évalué à 2.
[^] # Re: Au niveau de l'existant
Posté par bubar🦥 (site web personnel) . Évalué à 2.
Pour la fonctionnalité de snapshooting, détrompes toi car je pense qu'il s'agit d'une fonction très attendue. C'est une fonction qui va permettre de mieux supporter le rythme effréné de développement de linux et des logiciels libres. Et cela, pas que pour Mr et Mme Michu...
En se situant au niveau du FS, la fonction devient transversale, s'affranchit des trucs-uiq-marchent-mal comme l'option de Yum, de Urpmi et de Apt. Qui prends tout les fichiers du système, et non le système lui même. IRL les fichiers contenus pas le système sont plus importants que le système lui même, dans de très nombreux cas
Pour avoir pas mal manipulé OpenSolaris, après des tests persos et après les bons conseils de Bruno B, je peux dire que c'est vraiment un régal à l'usage. En fait c'est même une killer feature. Car je n'en doute (je vérifie même pas avant) que tout comme les FS ext, il sera possible de déporter le journal d'une machine sur une autre machine, et d'y tirer les snapshooting. Les systèmes de sauvegarde tels que nous les connaissons sont en train de disparaitre, doucement, mais surement.
C'est vraiment ce genre de fonctions, intégrées à bas niveau, qui va permettre d'avoir moins de machines "figées" recevant juste quelques mises à jour classiques (et encore...) parcequ'on a peur de les péter. Car sur ces machines aussi il faut valider les maj classiques sur une machine neutre. Cela ira tellement plus vite avec le snapshooting de fs...Moins de machines figées, plus de machines prête à suivre le rythme de développement de linux, moins de failles.
mes deux cents.
# Magie des snapshots !
Posté par Martin Peres (site web personnel) . Évalué à 3.
[^] # Re: Magie des snapshots !
Posté par Etienne Bagnoud (site web personnel) . Évalué à 10.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Magie des snapshots !
Posté par windu.2b . Évalué à 10.
Adrénaline garantie \o/
[^] # Re: Magie des snapshots !
Posté par Dabowl_92 . Évalué à 2.
# Pas si invisible que ça
Posté par claudex . Évalué à 6.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas si invisible que ça
Posté par Julien04 (site web personnel) . Évalué à 2.
[^] # Re: Pas si invisible que ça
Posté par Mildred (site web personnel) . Évalué à 4.
[^] # Re: Pas si invisible que ça
Posté par windu.2b . Évalué à 2.
[^] # Re: Pas si invisible que ça
Posté par zebra3 . Évalué à 9.
En version desktop, elle ne gère pas LVM, et crée deux partitions par défaut, / et swap. C'est vraiment une distribution rétrograde.
C'est peut-être pour ça qu'elle s'impose sur le bureau : elle imite Microsoft qui a compris que la clef du succès réside dans la pauvreté technique et la richesse du bling bling.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pas si invisible que ça
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Je sais pas si c'est déjà existant, mais ça serait pas mal.
[1] http://fr.wikipedia.org/wiki/Emmental
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Pas si invisible que ça
Posté par claudex . Évalué à 3.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas si invisible que ça
Posté par bubar🦥 (site web personnel) . Évalué à 2.
[^] # Re: Pas si invisible que ça
Posté par Psychofox (Mastodon) . Évalué à 2.
Quand on utilise un volume manager et des FS moderne, on crée des volumes à tour de bras pour chaque type d'usage.
[^] # Re: Pas si invisible que ça
Posté par Victor STINNER (site web personnel) . Évalué à 4.
Sinon pour ne pas perdre de fichier lorsqu'un "rollback" est fait par apt-get, il « suffit » que le système et la $HOME soient sur des partitions séparées.
# ZFS
Posté par thomas . Évalué à 10.
Si les modification apportées à un clone sont validées alors ont peu transformer ce clone en dataset à part entière avec la commande promote (le snapshot sous-jacent au clone devient un snapshot du nouveau dataset). On peut, ainsi, préparer une mise-à-jour d'application sur un clone, et si tout est OK, on le promeut et supprime l'ancien dataset orgininal.... pratique !
[^] # Re: ZFS
Posté par briaeros007 . Évalué à 6.
Sisi.
L'information n'est pas ex nihilo. La création d'un snapshot consomme bien de la place sur le fs (ne serait ce que pour conserver la racine de l'arbre et indiquer qu'il y a un snapshot).
Par contre cette information est extrêment faible, et ne dépend pas de la taille des données dans le snapshot
[^] # Re: ZFS
Posté par thomas . Évalué à 2.
D'ailleurs, en chipotant aussi, je dirais que ce sont les metadata du snapshot qui prennent un peu de place (nom, source dataset), le snapshot en lui même prenant effectivement 0 octet :-)
# BRTF
Posté par Refuznik . Évalué à -2.
[^] # Re: BRTF
Posté par bubar🦥 (site web personnel) . Évalué à 3.
http://fr.wikipedia.org/wiki/Btrfs
quoi ? je suis non neutre, aussi ? :p
# Mais say super!
Posté par Grunt . Évalué à 2.
:+)
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Mais say super!
Posté par MrLapinot (site web personnel) . Évalué à 3.
# Waouw
Posté par Snarky . Évalué à 4.
# Cas des bases de données
Posté par Florian . Évalué à 2.
En général, à moins de geler la base, il n'y a aucun moyen de savoir si les fichiers de base sont cohérents au moment du snapshot. La restauration du snapshot peut donc entraîner une corruption de la base.
Btrfs apporte-t-il une solution à ce problème ?
[^] # Re: Cas des bases de données
Posté par IsNotGood . Évalué à 2.
[^] # Re: Cas des bases de données
Posté par IsNotGood . Évalué à 1.
Non. Pas avec un bon gestionnaire de donné puisqu'il doit aussi supporter les coupures de courrant par exemple.
MySQL pose problème car par défaut il n'utilise pas flush.
[^] # Re: Cas des bases de données
Posté par steckdenis (site web personnel) . Évalué à 4.
# Pas de titre
Posté par Dr BG (site web personnel) . Évalué à 10.
Un instantané, quoi. Mais le français, c'est has been.
[^] # Re: Pas de titre
Posté par mansuetus (site web personnel) . Évalué à 5.
# Faisable avec LVM
Posté par Anthony Jaguenaud . Évalué à 1.
arrêt BD, snapshot, start BD, montage dans /saved_fs, sauvagarde, destruction du snapshot.
Par contre, je ne sais pas si on peut revenir en arrière.
[^] # Re: Faisable avec LVM
Posté par Grunt . Évalué à 10.
start BD
Ben ça, déjà, ça pue. :D
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
# git ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: git ?
Posté par Matthieu Moy (site web personnel) . Évalué à 6.
Les snapshots, c'est un truc à peu près instantané quelle que soit la taille de la partition, et qui ne stocke pas en double les trucs qui n'ont pas à l'être.
Par ailleurs, une fonctionnalité importante d'un gestionnaire de backup est de pouvoir oublier certains snapshots (typiquement, faire un snapshot par minute conservé quelques minutes, puis un par heure conservé sur la journée, puis un par jour, ...). Avec Git, au contraire, une fonctionnalité essentielle est qu'on ne peut pas éditer l'historique sans tout casser.
Bref, un système de backup à base de snapshot et un gestionnaire de versions, c'est pas fait pour la même chose, et ça ne répond pas aux mêmes besoins.
# Réinventer la roue ?
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 6.
Ça fait trente ans que VMS fait ça.
# Bonne idée
Posté par Mildred (site web personnel) . Évalué à 1.
Finalement, je n'ai pas perdu grand chose. Principalement le dossier Desktop (qui me sert de poubelle en quelque sorte) mais j'ai eu peur sur le moment.
Vive btrfs
# BtrFS et Wikipedia
Posté par windu.2b . Évalué à 2.
Alors :
* Soit y a quelqu'un qui s'est chié sur la page de WP ;
* Soit j'ai raté un épisode dans l'évolution de BtrFS ;
* Soit j'ai pas compris ce que le mot "introduction" voulait dire (ça, c'est vrai).
Pour info, la page en:Btrfs indique "Introduced Stable: Yet to be released".
[^] # Re: BtrFS et Wikipedia
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Par contre, le format "on disk" a encore changé récemment (pour Linux 2.6.31, pour améliorer les performances, certes) :
http://linuxfr.org/2009/09/10/25848.html#btrfs
Extrait du wiki de btrfs : « Btrfs is under heavy development, and is not suitable for any uses other than benchmarking and review. The Btrfs disk format is not yet finalized, but it will only be changed if a critical bug is found and no workarounds are possible. »
http://btrfs.wiki.kernel.org/index.php/Main_Page
Libre à vous de tester, ou pas :-)
# "Autre cas, la fameuse «restauration système» de Windows..."
Posté par NickNolte . Évalué à 1.
-->[]
# FS/Noyau
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Un FS, c'est à quel point dépendant du noyau ? C'est pas supposé justement être un truc assez abstrait pour être manipulé par n'importe qui ?
Ou alors est-ce que la phrase est un raccourci pour (le très long et chiant) « un système de fichiers prévu comme choix par défaut pour les prochaines distributions d'OS qui tournent sous un noyau GNU/Linux » ?
En tout cas, ça a l'air cool, mais il me reste deux/trois questions
Le snapshot reste-t-il sur la même partoche ? Le FS est-il distribué ? Peut-on prendre un instantané d'un(e liste de) répertoire(s) et non de toute une partition ou de tout le système ? Peut-on prendre plusieurs instantanés et revenir de n en arrière ? Peut-on restaurer chez soit un snapshot d'un autre système (en supposant que les deux étaient identiques lors de la « photo ») ?
[^] # Re: FS/Noyau
Posté par windu.2b . Évalué à 2.
Il n'y a pas réécriture des données, mais seulement création des métadonnées le déclarant (un peu comme la création d'un tag dans un dépôt SVN : ça ne duplique pas le code, ça ne fait que marquer une révision particulière).
[^] # Re: FS/Noyau
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Donc une simple écriture incrémentale¹ sur le disque. J'ai rien contre, mais je pense qu'il vaut mieux passer du temps sur des trucs utiles comme de bon FS distribués alors…
¹: Je m'imagine bien que je simplifie là, mais bon. On n'est plus à l'âge d'augmenter la vitesse des processeurs, ni à celui de pleurer quand on fait rm -rf /
[^] # Re: FS/Noyau
Posté par wismerhill . Évalué à 3.
Toutes les personnes qui utilisent un ordinateur ont besoin d'un système de fichiers localement, les cas d'utilisations d'un FS distribué sont plus ciblés et concernent beaucoup moins de monde.
Il vaut mieux passer son temps sur un FS qui profitera à tout le monde.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.