Microsoft propose depuis ce week-end un système d’extension open source dédié aux dépôts Git. Nommé GVFS, il est proposé à la communauté et ambitionne d’accélérer très nettement certaines opérations en virtualisant les ressources.
GVFS, Git Virtual File System, est un projet de Microsoft sous licence MIT. Il est disponible depuis peu dans un dépôt Git, l’éditeur espérant fédérer une communauté de développeurs autour d’un objectif bien précis : rendre les opérations Git bien plus rapides sur les dépôts de projets contenant des millions de lignes de code.
La problématique des très gros projets
Microsoft articule ses explications autour d’un exemple emblématique : Windows. Le code source du système (on imagine que l’éditeur parle de la version 10) s’étale en effet sur pas moins de 3,5 millions de fichiers, contenant chacun un nombre indéfini de lignes de code. En tout, cette montagne de données fait son poids : la bagatelle de 270 Go.
Or, Microsoft indique que s’il apprécie particulièrement Git, le système de gestion de versions voit ses performances dégradées dans le cas de très gros projets. Toujours sur l’exemple de Windows, un « checkout » peut prendre ainsi jusqu’à 3 heures, un « clone » plus de 12 heures et même un simple « status » peut durer jusqu’à 10 minutes.
On notera que Gabriel Aul, qui dirigeait auparavant le programme de test Windows Insider, participe également au projet. Il indique dans un tweet que Microsoft transfère actuellement son SCM (Source Code Management), ce qui explique les travaux réalisés dans le même temps, l’éditeur souhaitait avant tout répondre à ses propres contraintes.
Un système de fichiers virtualisé
GVFS virtualise en fait le système de fichiers sous-jacent au dépôt. Il laisse apparaître tous les fichiers comme s’ils étaient bien là, mais ne les récupère en réalité que lorsqu’un utilisateur cherche à l’ouvrir pour la première fois. Un fonctionnement qui offre selon Microsoft plusieurs avantages, notamment l’absence de modification dans les environnements de développement et les différents outils de compilation.
Le principal, ce sont évidemment les performances de ce système quand il faut lancer des commandes Git. « clone » ne nécessiterait ainsi plus que quelques minutes au lieu d’une douzaine d’heures, un « checkout » environ 30 secondes au lieu de deux à trois heures, et un « status » quatre ou cinq secondes au lieu de dix minutes. L’éditeur insiste d’ailleurs : il ne s’agit que d’un premier jet, et il est possible de faire encore mieux.
Pour comprendre le fonctionnement de GVFS, il faut aborder le concept « d’hydratation ». On parle d’un fichier « hydraté » quand une coquille quasiment vide existant en mémoire est remplie avec des données réelles. L’évocation de ce fichier devient alors le fichier à proprement parler. Or, c’est là le mécanisme central de GVFS. Les opérations ne s’exécutent que sur des fichiers « hydratés », puisque les autres correspondent à des données qui n’ont pas été utilisées récemment.
For those who ask what I've been working on, here's a bit. We're moving our SCM to Git and invented a bit of tech: https://t.co/rQdcOx6wI5
— Gabriel Aul (@GabeAul) 3 février 2017
Ne reste qu'à motiver la communauté autour du projet
Ce fonctionnement correspond selon Microsoft à l’utilisation faite de Git en général : « Dans un dépôt aussi imposant, aucun développeur ne compile l’arbre entier des sources. Au lieu de ça, ils téléchargent généralement les dernières modifications depuis la plus récente build et ne compilent alors qu’une petite partie des sources, liées à ce qu’ils ont modifié. Donc même s’il y a plus de trois millions de fichiers dans le dépôt, un développeur typique n’aura besoin que de télécharger et utiliser 50 000 à 100 000 de ces fichiers ».
Évidemment, il y a peu de chances que les développeurs aient des dépôts aussi vastes, mais le gain de temps peut être manifeste et le projet est sous licence MIT. Reste à voir si la communauté répondra présente. Tous ceux qui se penchent sur GVFS pourront se rendre sur le dépôt Git du projet, qui contient d’ailleurs toutes les instructions d’installation. Cette dernière passe par l’utilisation d’un pilote spécifique, qui demandera de désactiver momentanément BitLocker pour être mis en place.
Commentaires (80)
#1
GIT étant conçu comme un système de fichiers (dixit Linus Torvalds), l’effort technique n’est pas énorme.
Quand à la virtualisation (=hydratation à la demande) , c’est pas non plus révolutionnaire pour tous les admins qui ont connu les sauvegardes sur bandes.
Bref, une très bonne idée de Ms de proposer ce GVFS, mais rien d’exceptionnel question ingénierie.
Le “we invented a bit of tech” est un peu “too mutch”, de mon point de vue.
#2
Sinon, pour les grosses bases de logiciel, il y a repo.
Évidemment, pour Microsoft, il y a 2 inconvénients:
#3
Est-ce que ce système de fichier est/sera disponible sous Linux ?
Nota : Ceci n’est pas un troll.
#4
le problème initial, ce ne serait pas d’avoir un dépôt Git unique pour 3,5 millions de fichiers ?
Y’avait pas moyen de subdiviser un peu les choses, justement pour ne pas tomber dans ce genre de cas limite ?
#5
Tu peux lire cette article de blog pour avoir un aperçu un peu plus complet des raisons qui les ont fait choisir Git :https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-git-and-some-back-sto…
(A noter que Microsoft n’est pas le seul à fonctionner avec un énorme repository, Google semble faire de même)
#6
Pour comprendre le fonctionnement de GVFS, il faut aborder le concept
« d’hydratation ». On parle d’un fichier « hydraté » quand une coquille
quasiment vide existant en mémoire est remplie avec des données réelles.
L’évocation de ce fichier devient alors le fichier à proprement parler.
Rien compris
#7
Nécessite InnoSetup, qui est disponible uniquement pour Windows il semblerait.
" />
Sinon bonne idée de leur part, même si des projets aussi énormes ça court pas les rues. Et moins je dépends de Google (repo), mieux je me porte !
#8
#9
#10
Cool
#11
Le code source du système (on imagine que l’éditeur parle de la version 10) s’étale en effet sur pas moins de 3,5 millions de fichiers, contenant chacun un nombre indéfini de lignes de code. En tout, cette montagne de données fait son poids : la bagatelle de 270 Go.
Si ces chiffres sont exacts, c’est gigantesque
(cela dit ça ne m’étonne pas trop que ce soit un peu le b*rdel chez eux, quand on a connu le style de codage de Redmond dans le temps (non, pas un troll))
NB : on peut comparer à Linux, qui en plus tourne sur un nombre d’architectures impressionnant, et sachant que les drivers sont dedans et prennent une grosse place.
#12
C’est comme si tous les fichiers faisaient “zéro octet” tant que tu n’as pas besoin d’accéder au contenu.
Des que tu accèdes au contenu, le fichier est réhydraté (rempli avec son contenu).
Du coup, toutes les opérations de gestion (duplication, déplacement, navigation …) se font sur très peu de volume.
#13
C’est comme le bolino.
T’as juste l’essentiel, et quant tu rajoutes de l’eau au fur et à mesure ça prend du volume.
#14
Non c’est pas étonnant, le code source est toujours plus gros que le code compilé.
J’ai toujours vu ça du moins.
#15
Ça peut être assez chiant de devoir gérer beaucoup de repo différents, en terme d’administration, et tout ça.
Sinon, ils ont conscience que gvfs c’est gnome virtual filesystem, et que reprendre le nom ça va juste rajouter de la confusion si jamais leur truc arrive sous linux ?
#16
C’était justement dans ce sens là que je te donnais ce lien
" />
Les choix sont indiqués, et ils parlent des pistes qu’ils ont envisagé.
#17
On voit qu’ils ne connaissent pas du tout la communauté open source chez Microsoft. GVFS, c’est déjà pris comme nom…
#18
#19
helloworld.c –> 63 octets
" />
helloworld.exe –> 6300 octets
#20
Non justement, ça a demandé du boulot, au point qu’ils ont du créer une extension de l’API HTTP de Git.
D’ailleurs, du coup ça ne marche que sur les serveurs Git qui supportent gvfs.
#21
Passer à un système de fichiers virtuels, ça casse pas l’interet de GIT d’être un système distribué ?
Parce que du coup les fichiers restent sur le dépot central, et ne sont rappatriés qu’au besoin réel.
Si le répo central tombe ou n’est plus accessible, le dev est bloqué.
Et si ce répo est définitivement perdu…
#22
#23
Et suivant les cas ça peut même etre très chiant -> cf les submodules.
Une seule répo a ses abantages…
#24
#25
#26
#27
#28
des drivers préintégrés, il y en a des milliers ET… c’est moins que par le passé. Depuis que Microsoft a forcé le format WHQL, les constructeurs ont factorisés leurs drivers et Microsoft propose meme des drivers dit génériques, que les constructeurs doivent gérer (standard d’un claiser USB par exemple).
" />
Sous Windows XP, le premier à avoir des drivers intégrés, c’etait déjà 15% du poids du CD juste pour les drivers d’imprimante, alors que les gens ont au mieux UNE imprimante.
maintenant oui tu as un CD avec le pilote dessus mais dans 90% des cas, ton périphérique marche en grande partie sans ce CD, et grâce au pilote générique.
c’était la minute culture car on dévie du sujet
#29
#30
Enfin, si la description de la taille des sources de Windows te paraît normale, OK.
Je pense que ça inclut l’historique.
Sinon, à 30 caractères / ligne de code en moyenne (ce qui est une moyenne haute), on serait à 10 milliards de lignes de code pour arriver à cette taille là.
À ma connaissance, on est au moins un ordre de grandeur en dessous, plutôt 2 (~100 millions de ligne de code).
Par rapport au rapport source / taille du binaire, ça dépend beaucoup. Perso, sur mes projets, j’ai pas mal de cas où le binaire est plus gros que le source (avec les templates C++, c’est assez fréquent). Et je parle bien de l’exécutable compilé en release.
#31
rien n’empêche de l’utiliser localement sur sa machine: on pourrait ainsi avoir sur sa machine de dev un seul clone git complet de 270GB sur lequel tourne un serveur GVFS que l’on synchronise quand on veut à partir des remotes que l’on veut.
Du coup on garde le distribué tout en ayant les gains énormes de vitesse sur les clones, les checkouts et les status
#32
Une partie du problème de Git sous Windows vient justement de WIndows qui est beaucoup plus lent que Linux pour les opérations les plus courantes de Git. Ce n’est pas un hasard: quand il y développé Git, LinusTorvalds cherchait le maximum de performances et comme il est plus que bien placé pour savoir ce qui va vite sous Linux, il y basé l’architecture de Git spécifiquement pour Linux (au point d’en abuser avec quelques trucs comme l’attribut de montage ‘noatime’). Donc forcément ça ne va pas aussi vit sur Windows qui déjà à la base a un problème de performance avec les grosses opérations sur les systèmes de fichier.
Le code d’un noyau Linux prend actuellement environ 800Mo avec environ 60’000 fichiers et même sur mon vieux AMD A10-7850K il ne faut que 0.5 secondes pour faire un git status ou un git diff sur tout le code. A priori même avec un code délirant de 270Go ça ne devrait pas prendre tellement plus de 3 minutes. Délirant car ça semble difficile de croire qu’il ne soit pas possible d’organiser autant de données dans de multiples sous-projets, une possibilité qui est maintenant très bien supportée par Git. Il doit y avoir un sérieux problème historique d’organisation des données…
Finalement il faut rappeler ici que Git a pour but principale de pouvoir fonctionner de façon totalement décentralisée, ce qui implique une copie complète locale du dépôt. Il y a quelques possibilités pour augmenter les performances en limitant le transfert initial, mais cela peut demander des transferts ultérieurs. La proposition de Microsoft semble miser beaucoup sur cette technique mais la conséquence est qu’il faut certainement un lien constant avec un serveur central.
#33
#34
#35
Ça veut dire qu’il faut avoir obligatoirement accès au repo pour bosser, ou il y a un mode “offline” quand même ?
#36
#37
#38
Au premier git diff ou git status, il va devoir lire les 270Go, non ?
" />
#39
#40
#41
De l’opensource ? part Microsoft ?!
License MIT
je me disais aussi.
Microsoft a toujours aimer linux mais pas GNU.
#42
On est pas dredi mais
Par ce que tu a déjà vue un windows rapide toi ?
#43
“And lastly, GVFS relies on a protocol extension that any service can implement; the protocol is available athttps://github.com/Microsoft/gvfs/blob/master/Protocol.md ”
#44
#45
pour ton 1), le kernel Linux gère lui aussi beaucoup de drivers (et peut être même plus que windows…). Pourtant il ne fait “que” 800Mo (soit ~300 fois moins), sachant qu’il a démarré il y a 25 ans donc bon…
Le “truc” c’est que windows c’est le kernel Linux + la glibc + x.org + qt + KDE (ou un autre ;)) + konqueror + kalc + …
Et ce qu’il disent c’est que tout est super imbriqué.
Après peut être qu’il vont au fur et à mesure désimbriquer certaines parties (je pense que la calculatrice doit pouvoir être un projet à part entière facilement ;) ) et ils auront moins de super repos mais pour le moment c’est trop compliqué.
J’y vois en tout cas un avantage de l’open source qui a permis d’avoir des repos à taille humaine (enfin, KDE c’est quand même 21M de lignes de code mais explosé en 300 projets)
#46
#47
#48
–Sur mon PC actuel ouais.–
Si tu le dit jte croi :)
On commence a voir ça de plus en plus non pas par ce que windows devient bon.
mais par ce que les drivers sont mieux développer du a l’unification des windows (prochainement disponible windows 10 cloud).
Perso si tu compare xp a windows 10 il y a un gouffre en terme de performance (en terme de sécu aussi) mais bon est ce comparable ?
On continuera a voir ce de différence temps que les constructeurs de matériels ne donneront pas les manuels de leur hardware.
Sinon sur ta machine perso tu est sure d’avoir compiler le kernel correctement ?
Un nextimpactient avais fais un très bon tuto la dessus
voila le lien
#49
#50
Moi ça me fait penser au système utilisé par onedrive. Ca a du bon et du mauvais: l’avantage de la copie locale c’est qu’en cas de pépin on a un backup. Mais d’un autre coté ça permet de faire économiser beaucoup de place!
#51
Pour ton point 2 c’est la base du libre non ? Les ingénieurs Intel faisant des comits sur Linux ne le font pas pour améliorer le support d’ARM ou des processeur AMD..
Et aujourd’hui Linux n’est pas développé par 3 gus dans un garage mais justement par des multinationales qui voient leurs intérêts avant tout..
#52
Définie moi “besoin spécifique” ^^
j’utilise gentoo en dehors de trisquel donc “besoin spécifique” pour moi c’est “si j’utilise pas il a rien a faire ici”
Sinon j’ai bien compris ton message ;)
Passe une bonne soirer.
#53
–qu’il faut certainement un lien constant avec un serveur central.
–
Vue que Microsoft va vers le cloud (windows 10 cloud) c’est pas étonnant.
#54
#55
Je veux pas dire une connerie mais le système est semblable a se qui existé avec OneDrive avec les fichiers coquille quasiment vide. Mais avec Windows 10 il l’on retiré :(
#56
#57
#58
Git n’est pas toujours utilisé en système distribué. En fait les règles dépendent un peu de la méthode de travail de l’entreprise, mais ce n’est pas rare du tout d’avoir des développeurs qui poussent vers un repo central unique, et aucun lien entre les différents développeurs.
#59
#60
En même temps on n’utilise pas une gentoo pour autre chose qu’un besoin très spécifique, celui de n’avoir que ce qu’on veut sur sa machine ;-)
Même pour des barbus, gentoo c’est un peu hardcore quand même.
#61
#62
Certes, les ratios sont pas les mêmes.
" />
Hors-sujet, mais ceux que ca intéresse peuvent voir le code source (40 ko, hors directx) de la demo “Elevated” (4k)
#63
Ah, et j’oubliais le PDF qui explique la mise au point du truc.
/fin du hors-sujet/
#64
C’est même bien plus qu’une simple conviction: c’est confirmé par un développeur de MIcrosoft:
 http://www.zdnet.com/article/anonymous-msft-developer-admits-linux-is-faster-tha…
Cela dit, dans le cas de Git c’est pas vraiment difficile à constater tant l’architecture de Git est optimisée pour Linux.
La page suivante  https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-git-and-some-back-sto… est très intéressante et montre bien que GVFS est une couche qui permet d’éviter au maximum l’utilisation du système de fichier local qui dans leur cas est NTFS. Et ce au prix de devoir être connecté au serveur à chaque fois d’un nouveau fichier est lu.
#65
#66
apres toutes ces années il n’y a eu aucun dev indelicat pour faire un git clone sur son ordi, un coup de winrar, et passer le tout sur piratebay ?
#67
#68
#69
bla bla bla vous êtes des trolls,… c’est Honteux !
#fakenews
#70
#71
#72
#73
il y a aussi le fait que les demomakers utilisent des outils pour compresser l’exécutable obtenu en bout de chaine. Avec UPX ou .kkrunchy par exemple pour ne citer que ceux qui me viennent spontanément à l’esprit.
#74
Dément mais pas étonnant. Le code source contient toutes les ressources (images, vidéos, etc), beaucoup beaucoup beaucoup de texte non compressé, etc. Probablement le code des outils qui servent à builder l’OS, à tester chez les partenaires, à générer des mises à jour, et des milliers de choses qu’on ne connaît pas.
Non à vrai dire ça ne m’étonne pas, ça monte très vite le nombre de lignes de code quand on documente proprement ce qu’on fait.
#75
#76
Pas 2 Go, pas 27 Go (punaise déjà ce serait bien gros), mais DEUX. CENT. SOIXANTE. DIX. GIGAS…
J’arrive pas à piger, mais je m’en remettrai :-) .
Je vois une explication éventuelle, c’est qu’ils gardent toutes les révisions hebdomadaires depuis des années, ça doit bien faire enfler.
#77
Rien n’indique qu’il n’y a qu’un seul OS. D’ailleurs on peut lire sur d’autres sites qu’ils ont tous les Windows dans le même repo.
Et il y a un paquet de versions Windows…
#78
#79
#80
Peut-être, mais même avec les binaires, OMG !