Storage Developer Conference - #28 New Fresh Open Source Object Storage

Episode Date: November 23, 2016

Hello, everybody. Mark Carlson here, SNEA Technical Council Chair. Welcome to the SDC Podcast. Every week, the SDC Podcast presents important technical topics to the developer community. Each episode is hand-selected by the SNEA Technical Council from the presentations at our annual Storage Developer Conference. The link to the slides is available in the show notes at snea.org slash podcast. You are listening to SDC Podcast Episode 28. Today we hear from Jean-François Smigielski, co-founder and R&D manager, OpenIO, as he presents New Fresh Open Source Object storage from the 2016 Storage Developer Conference.

Nice to meet you, I'm Jean-François Smigelski, I'm a co-founder of OpenIO, a French startup that provides an object storage nearly completely open source and based in France. I'm here to present the solution, how we made it, what was the starting point, how we made it, what was the starting point, how we developed it and what are the current developments. So let's start with a little history of the company. The first idea started in 2006 when we had too many data to store Nous avions trop de données à stocker et à gérer. C'était dans le contexte de la gestion d'une grande email, une grande email, beaucoup d'emails pour les services de l'Internet français.

Le développement a commencé en 2007, est entré en production en une période courte après. En 2009, nous avons stocké 1 petabyte. La solution a été open source en 2012. La capacité de stockage a été réduite à 15 petabytes en 2014. Et puis nous avons fortifié OpenIO sur le projet il y a un an. Nous sommes présentement présents à Lille, au nord de la France,

pour les gens qui le connaissent ici. Nous avons aussi une présence à Tokyo, San Francisco, Montréal et Madrid. Faites-lez contacter si vous voulez un représentant à ce point. Ce que nous avons fait, c'est que cette solution

a été utilisée pour gérer, je disais, 15 petabytes pour 60 millions d'end-users en d'autres termes, tous les Français avec leurs emails de l'ISP, avec des SLAs assez forts environ 100 millisecondes pour obtenir 1 MB de données pour chacun en même temps. C'est pourquoi la plateforme est assez forte, elle est servie à l'intérieur et à l'extérieur d'approximément 50 Gbps de stream. C'est une usage assez intensive pour ce qui a été décidé dé pour être appelé Storage. Et cela a été utilisé pour les emails et les clouds de consommation, toutes les vidéos, les archives, les photos, les contacts et les images des galeries que toutes les personnes ont.

Comment est-ce que nous sommes venus faire une société, une solution de software défini pour le storage d'objets? Je vais essayer de décrire, point, étape par étape, toutes les idées dans le processus. La première est la douleur, l'échec initial que nous avons eu. Nous avions trop de données, le progrès de la croissance a montré une accélération qui ne devait pas s'arrêter. showed an acceleration that should not stop. The data was stored in silos, sharded, so inducing migration between the silos and so on, was operated by too many people. In other words, it cost too much, far too much for storing and managing the data. So it was time to learn and reboot the solution to make

something different. The first thing we made was just considering that we were et de réutiliser la solution pour faire quelque chose de différent. La première chose que nous avons faite, c'était de considérer que nous étions en train de servir des applications qui consommaient les données d'une manière qui n'était pas amicale avec le stockage à cause d'une lasagne d'une grosse stack d'interfaces et... une tasse de interfaces, et parfois chaque interface fonctionne comme une boîte à cartes.

Je suis désolé pour mon anglais, mais je ne suis pas natif, donc j'ai parfois besoin de temps pour trouver mes mots. Il apparaît très clairement qu'il était nécessaire d'avoir une solution de storage qui était consciente des applications, qui donnait toutes les clés à l'application pour être utilisée, managée de manière pragmatique, et qui offrait plus d'API, de kits de développement de software, que quelque chose comme POS comme POSIX pour accéder aux données. La deuxième chose que nous avons remarqué c'est que les données n'ont pas les mêmes caractéristiques

concernant la consommation de l'Io. Il y avait beaucoup de petits fichiers qui ont fait toute l'opération de l'Io qui étaient modifiés presque tout le temps. C'est typiquement le cas du index des données. De l'autre côté, il y a des files énormes, assez immutables, ou au moins pas souvent modifiées, qui ont consommé la plupart de la capacité, presque 90%,

mais qui n'ont jamais été... qui ont été causées par la faible Io. C'est typiquement le cas des car il n'y avait pas d'Io. C'est typiquement le cas des e-mails de la boîte mail. Il était donc évident que collocer les deux données sur le même stockage, sur les mêmes dispositifs, était la meilleure idée que nous pouvions avoir. Il y a donc une indication, une clé, que séparer les données de base sur des équipements séparés serait une bonne idée. La deuxième considération que nous avons eu est que... Désolé pour les couleurs, elles ne rendent pas comme prévu.

Nous n'aimons pas provisionner une plateforme entière à la fois. Nous aimons commencer en petit, grandir quand nécessaire, et grandir sans limites si possible, et même recycler des outils, mais les délivrer en continu. Je ne veux pas construire une plateforme pour 10 petabytes

à un moment, parce que je sais que je vais en avoir besoin dans 5 ans. Je préfère avoir 1 petabyte sans nécess gigabyte, 1 terabyte, etc. Nous devons donc pouvoir gérer les délais ininterruptés à la base quotidienne. Ce problème de l'investissement en temps réel est que cela apporte une hétérogénéité à la plateforme. Quand vous updatez la plateforme, la plateforme change de hardware,

la nouvelle plateforme a de meilleures caractéristiques, elle est plus capable. Vous pouvez récycler la plateforme, par exemple vous décommissionnez la plateforme et vous pouvez la réutiliser dans votre plateforme sans avoir à dépenser de l du prix pour la acheter. Vous pourriez signer des deals de vendeurs, apporter de nouveaux outils avec différentes capacités, une meilleure latence, une meilleure capacité, une meilleure quantité de bandes, je ne sais pas. Vous devez donc gérer l'hétérogénéité et encore plus,

vous devez être prêt à vous adapter à la versatilité de la plateforme. Et c'est quelque chose que nous avons pris en compte quand nous avons désigné la solution. Le troisième point est que nous gérons les humains. Les humains agissent, au moins en France, nous sommes juste dans une petite partie de temps. Ou, en même temps, ils lisent leurs emails pendant le temps de sortie du travail, à la nuit, quand le travail s'arrête, et juste avant la nuit. Donc, vous avez des slots de temps bien identifiés pendant le jour, où toutes les quantités et la capacité de hauteur doivent être disponibles aux utilisateurs et dans la partie dernière du temps où la plateforme est disponible pour les admins

pour l'opérer. Nous avons donc en tête le but de la flexibilité pour la plateforme dans le sens que si vous voulez le faire, vous devez le construire suffisamment pour les utilisateurs, et le faire disponible pour les opérations à des moments spécifiques. Vous ne devriez pas, par exemple, rebalancer votre data pendant une semaine, pendant le tout le jour. Typiquement, vous devez pouvoir arrêter cela pendant les heures de pique. Vous gérez les humains, mais vous les servez. C'est le point fort. L'expérience utilisateur est importante. Vous devez rester dans une latence assez courte. Ce n'est pas extrêmement courte. C'est quelque chose qui a été assez difficile à atteindre, mais nous l'avons fait.

Il faut environ 20 millisecondes pour obtenir les premières bytes de données, 100 secondes pour obtenir à l'avantage 1 MB de données. Vous devez faire cela pour 100 millions d'utilisateurs, qui peuvent tous avoir jusqu'à 1 million de contenus dans chaque boîte mail. hundred millions of users than can all have up to one million content in each mailbox. This is typical. Also the humans act together at the same hour. They tend to use only the recent data and they tend to ignore the data that is bigger. They also have both effects.

They all consume the same data at the same time, typical for videos and so on. et qui ont des effets de buzz qui consomment les mêmes données et qui sont typiques pour les vidéos. Donc vous avez des clés sur les factures de caches et des roues intéressantes parce que les données sont réutilisées sur des roues plus chaudes et les données sont envoyées sur des caches plus chauds. Donc, avec ce point en tête, nous avons désigné notre architecture. D'abord, le double hump a montré que la splittage du chaud et du froid,

même dans plus d'une splittage, mais aussi la splittage et la déchargée de données plus profondes, les plus froid. Nous devrions faire cela sur des drives indépendants, pour éviter le stockage de la main, des vaches, etc. Juste un tas de disques, et offrir un colleur de software pour les agrégater. L'idée de l'agrégat, que nous avions à un moment,

mais que nous avons décidé de éviter, c'est d'utiliser le hash consistant pour le placer, pour placer le data, juste à cause du rebalancement qui se passe chaque fois que vous voulez escaler votre plateforme et chaque fois que vous voulez décommissionner de l'hardware. Quand vous devez déplacer le data, et nous l'avons vu, vous ne pouvez pas le faire quand vous voulez, si vous voulez escaler le data sur une base quotidienne, vous ne pouvez pas rebalancer tout le temps. Donc, si vous voulez faire ça, faire l'augmentation de la quantité de données, évitez le tâchage consistant.

Donc, si vous ne pouvez pas faire ça, vous devez faire d'une autre façon. Et ce que nous avons proposé et accompli, c'est qu'envers le savoir, de choisir et de se rappeler. La partie choisir de l'idée est utilisée par une équipe de software appelée Conscience. Je ne vais pas élaborer beaucoup de ceci, car c'est complètement essentiel dans la solution, mais c'est très simple. Et Conscience est responsable de choisir les meilleures nodes pour placer les données. Et la partie de se rappeler de lael est utilisée par les directrices,

un problème de recherche régulier pour quelque chose que nous connaissons dans la science de la computer. Donc le conscient responsable de choisir les nodes, en fait, est comme un hub. Il distribue les snapshots récentes de la plateforme pour les autres nodes, afin que les nodes qui ont besoin de faire des services pour un projet, découvrent les collègues, les qualifient en donnant un score, en prenant en compte toutes les caractéristiques internes de chaque service, et en puissant faire un balancement de charge basé sur le score donné à chaque service. Les directrices responsables de la reconnaissance de la location pour les 10 ou 14 contenus sont des choses assez difficiles à gérer en entier, mais qui peuvent être divisées en problèmes triviales

lorsque vous arrêtez la nommation des objets à un point, et c'est ce que nous avons fait avec la nommation dans la direction du conteneur. Nous allons associer un conteneur par utilisateur. Nous aurons 100 millions de conteneurs, c'est quelque chose que la directive peut gérer. Et chaque conteneur apparaît dans le contenu de ce utilisateur. Donc c'est une directive de deux niveaux. Voyons un peu plus en détail comment fonctionne chaque des layers. Le premier, une directive de haut niveau, est la directive des services. Elle est liée à un tableau de hash. Comme vous le savez, il y a un tableau de hash qui est divisé en 68 blocs.

Et chaque bloc est chargé sur un fil SQLite plein qui peut être répliqué plusieurs fois. Vous décidez quand vous déployez une plateforme. Nous utilisons régulièrement trois réplicas pour que vous puissiez perdre un node et le rébuilder et gérer un erreur. Et l'avantage de cela est que cette directive est extrêmement statique. Vous ne bougez pas les containers, parce que les données ne sont pas si grandes. Les containers, 100 millions de données ne sont pas des données complètement énormes. Vous pouvez les provisionner facilement au début de la plateforme. Vous pouvez donc les garder en cache assez facilement dans tous les clients. Le second niveau vous donne vraiment la vue objectif du stockage. Pouvoir, écrire, éditer, liste, pagination, etc.

Il gère les versions sur le contenu, les lignes difficiles à être efficaces sur les copies, les renommées, etc. Il gère les propriétés associées au contenu. Il génère des notifications qui vous permettent de déclencher un management asynchroneasynchronisme des données déployées. Quand le contenu est mis en place, qu'est-ce que je peux faire avec ça? Le sauver? Le déplacer? Le dégager? Je ne sais pas, ce que vous voulez,

on donne la clé à l'application pour faire ce qu'elle a besoin. Et le directeur lui-même, chaque directeur, chaque conteneur, est aussi géré avec un seul fil SQLite, qui est aussi réplicé, et qui utilise exactement la même technologie, et est aussi backupé avec backlinks. Chaque point de contenu de la directive garde aussi le point de retour à la directive, afin de pouvoir reconstruire toute la couche de la directive tout sans réplique.

C'est très utile. Pour une architecture comme celle-ci, nous devons créer des outils de développement. Nous devons évidemment offrir des API, nous sommes une solution de software. Manager toute la complexité du directeur n'est pas la meilleure façon de le faire. Il ne faut pas le ré-implémenter chaque fois qu'il faut faire un autre SDK. Nous gérons cette tâche dans une proxy, que tous les SDK accèdent à HTTP et JSON, quelque chose qui est assez régulier pour les RPC. La connexion, les transferts de données à la stockage sont gérés par la proxy pour les données.

Toutes les tâches compliquées sont faites dans ces données, par exemple, le codage d'Azure pour gérer la durabilité des données etiquées comme la balance de charge, quand votre données sont répliquées, vous pouvez choisir le meilleur node pour les servir. Quand vous avez trois copies, choisissez la copie la plus chargée. Les proxys sont bien, mais parfois la latence est importante. Donc, le code qui gère les transferts de données dans le SDK a été insulé dans un code qui est disponible dans certains SDK. et on peut utiliser un SDK, typiquement C, quand on ne peut pas affronter la latence en traversant un gateway ou une proxy. Ça peut être un bouton-neige, désolé. Nous avons donc en outre plusieurs kits de développement de la software.

Python, qui est la première classe, la première citoyenne des API. C, qui est utilisé, on le verra plus tard, dans l'application d'emailing et Java, parce que c'est le plus apprécié En termes d'interfaces, on a des interfaces de réseau, on a de facto un standard Amazon S3 parce que quand on produit des stockages d'objets, on ne peut pas faire autrement que de les produire et Swift aussi, parce que c'est un standard de facto. Au-dessus de la solution open source, nous avons ce que nous appelons des additions spécifiques qui targetent les grands endroits du marché, typiquement les e-mails. Nous avons un connecteur dans Cyrus, Cyrus 3, qui est peut-être encore en bêta, donc vous ne le trouverez pas dans le service.5 par exemple. Dovecode qui est en développement

mais vous allez besoin actuellement de Dovecode Pro et Zimbra qui est développé par SinaCore. Nous avons une édition pour les marchés de médias avec des portes HTTP de TaylorMade qui vous permettent de streamer les données selon les standards du marché et 5 extensions systèmes qui vous permettent de monter le stockage d'objets en connecteur de fuse exposer le dans NFS, Samba ou autre chose que vous voulez qui soit sur la fuse. Voilà. Oh, désolé pour l'effet fudgy. Nous parlons beaucoup de flexibilité.

Nous avons un grand avantage, c'est que nous avons des pointeurs partout. Nous avons une directrice d'usages, où il y a des pointeurs pour les containers, une directrice de contenu dans chaque container. C'est facile de placer ce que vous voulez derrière le pointeur, ce qui est pointé. La solution générale que nous avons trouvée pour les besoins de flexibilité, est ce que nous appelons une politique de stockage. C'est la combinaison entre le pool de stockage et la fonction de protection des données. Le pool de stockage vous donne où vous storez les données et la protection des données,

comment vous les storez. C'est assez simple mais ça fait tout. Le pool de stockage vous donne l'obligation de faire un balancement de notes fin basé sur des tags installés sur les services. C'est bon parce que ça vous permet de définir les faussesir les contraintes de distance entre les services. Typiquement, je veux une copie en Amérique, deux copies en Europe, et si je ne trouve pas un service disponible en Europe, je mets la deuxième copie en Amérique, par exemple. Donc, ça ouvre complètement la porte à la distribution géographique. La protection des données, ce que je mets derrière est comment

sécuriser les données. Est-ce que vous les codez? 6 plus 3, 6 plus 4? Ou vous voulez juste une réplication de 3 copies? Ou vous voulez juste une seule copie parce que vous pouvez gérer la protection avec la hardware? C'est quelque chose qui est totalement configurable

dans la solution, la hardware. C'est quelque chose qui est totalement configurable dans la solution. Quand appliquez-vous la politique de stockage? Quand vous publiez les données pour la première fois. C'est configuré pour le contenu, il peut être spécifié. Si non, vous avez un valeur fondamentale pour le contenu, et si non, pour l'ensemble de l'account. Pour que tous les utilisateurs aient le même bénéfice, la même politique de storage.

Vous pouvez aussi la changer et la forcer pendant un processus de trigger asynchrone sur les données, triggeré par les notifications émises par les conteneurs. Et pourquoi changez-vous la politique de storage? Nous développons actuellement une politique de storage dynamique pour que vous puissiez dire que si le même type de données est juste un PDF, par exemple, qui ne contient pas le titre SDC 2016, envoyez-le sur le storage de la la call, car il ne sera pas utilisé dans le long terme. Si c'est un fichier.html, alors

le garder dans le storage local, dans le hot storage comme exemple. Les avantages que nous avons de l'implémentation de ceci sont la capacité de partitionner presque tout, les utilisateurs dans les classes, les utilisateurs de gold qui payent plus que les utilisateurs normaux, et ainsi de suite. La plateforme est aussi de faire des matchmaking entre les deux, avec des capacités très basses, de très haute capacité, de très petite capacité, mais de très basse latence, et ainsi de suite.

Pour avoir toutes les qualités de services de bonne qualité avec une telle fonction. Et si vous avez les éléments, la porte est aussi ouverte à la réduction de TCO et à l'optimisation du coût, parce que vous mettez juste ce qui est nécessaire pour servir les bons utilisateurs. Nous pouvons tirer sur plusieurs hardware, mais nous avons des pointeurs et c'était presque le premier pas, le premier pas évident pour pointer à quelque chose qui n'est pas sur votre plateforme à la première place et mettre cela sur le Cloud public. Pourquoi feriez-vous cela? Nous considérons le public tier comme un tapeur très lent mais actif. C'est-à-dire quelque chose de bien adapté à des données ultra-coldes. Vous pouvez bénéficier du coût de stockage basse des données.

Comment faire cela? et en plus, on ne peut pas bénéficier de la haute coût de la data. Comment faire? Si on a une tier, la meilleure façon de faire cela est de dédier une politique de storage à ces personnes. Donc, on peut dire que la pool est la tier publique, et la sécurité des datas, typiquement, pour une tier, est une seule storage, parce que la tier gère la sécurité des données. Vous devez juste embeder le connecteur dans la proxy. Vous pouvez remarquer que ça ne change rien dans l'application client.

Nous ne ressentons pas la nécessité de donner un accès direct au Cloud public juste parce que c'est, je dirais, lent par nature, mais parce que vous n'avez pas la même connectivité au public cloud que sur le premier, donc pas vraiment besoin d'y accéder directement. Et ça bénéficie vraiment du synchronisme introduit par les triggers. Juste parce que vous n'avez pas, vous n'avez pas envie de coller l'utilisateur à la délication typiquement du fichier, vous pouvez le faire plus tard, pas de problème, et dire que c'est OK, le fichier a été écrite, et parce que vous n'avez pas la vitesse de la bande pour absorber les pics des charges. Oui?

Donc, typiquement, le tiering est fait avec différents types de médias, pour que vous puissiez atteindre des gains de performance. Mais si vous faites du tiering from one public cloud to another, what criteria do you use to pick your tiering here, for lack of a better word? Given that everything is in cloud no matter what. This is a case we did not have yet. But that's something you configure in the, mais c'est quelque chose que vous configurez dans le...

Nous sommes habitués à dire que nous ne savons pas mieux que les opérateurs ce qui est bon pour eux. Je ne sais pas ce qui est le trigger pour eux pour faire bouger le data données d'un point à l'autre parce que c'est plus cher et qu'il est prêt à accepter le coût de transfert d'un point à l'autre. C'est quelque chose qu'il sait, je ne peux pas le savoir pour lui. L'application ne sait pas le prix du transfert par exemple. C'est quelque chose que vous devez configurer. Vous parlez de la portée, vous parlez de portée en termes de bandes, en termes de froid ou quoi? C'est ainsi que vous configurez l'application.

Comment dirais-je ça? Quand je discribe les politiques de storage dynamiques, vous décrivez des règles. Quand vous créez des données sur la plateforme, vous trouvez un fichier, vous voyez les métadatas, les caractéristiques, et vous décidez de faire quelque chose dessus. Si vous configurez le crawler avec une logique qui décide de déplacer le data de l'un côté à l'autre, vous avez fait la choix, vous avez fait la révaluation des coûts vous-même. prix que vous connaissez, mais il ne se dit pas que la plateforme de cloud Google existe ou que c'est plus cher, donc j'ai décidé de bouger. L'opérateur doit gérer cela. Donc, pas de changement énorme dans l'application client. Cela a été très facile à faire, juste avec l'aide de la proxy vers le data.

Nous avons un premier partenaire pour cela. Nous proposons maintenant, parce que nous avons déjà embed le connecteur, d'offler le data à Backblaze en storage de calls, quelque chose qui a été développé en juin et qui est déjà disponible dans la partie open source de la solution. Vous déployez OpenIO, vous voulez offrir vos données ultra-colle sur BlackBlaze, vous les configurez dans la politique de stockage, et laissez le crawler faire, et les données seront envoyées sur BlackBlaze tout de suite que la bande-bloc autorise cela.

Nous pouvons encore aller plus profond dans la description... Je vois des gens qui disent non... On peut encore aller plus profond dans la description. On a encore trop deérer, et ainsi de suite. Tous les layers apportent des bugs et latences, le host peut manquer, avoir trop de mémoire, et ainsi de suite. Pouvons-nous juste le déposer et offrir ceci immédiatement, disponible sur le réseau? Il y a une grande opportunité actuellement, et il y a un plugfest en cours sur le niveau de base. L'opportunité Kinectique, portée par Seagate, permet de directement exposer les drives connectés à la plateforme. Vous avez accès aux données sans avoir besoin de clés dans un assortiment.

Pour nous, c'est la bonne année. Nous avons introduit le drive K à l'interface client. Ici nous avons ressenti la nécessité de faire des accès directs, mais le proxy est aussi disponible dans la solution. Nous partageons exactement la même vision entre ce que veut offrir Seagate et what we want to do reducing the complexity reducing the cost and had give more ease to the gathering of a huge bunch of disks so this is something we are currently including i even invite you to meet us both all the the kinetic group that is present in the Sonoma demain et à rencontrer le Blackface qui est en train de se dérouler sur le niveau de base. Et juste, et pour finir,

je parle de stockage, mais ce n'est pas tout ce que l'application veut faire avec les données. L'application veut souvent processer les données, et si possible, dans un endroit qui est colloqué sur les données, parce que les coûts de transfert. L'application veut par exemple gérer les métadatas autour du data. Typiquement, mes datas sont partagées avec quelqu'un pour stocker les liens entre eux. Je veux faire des recherches en texte et ainsi de suite. C'est ce que nous proposons sur OpenIO parce que quand vous storez, et si vous recyclez

cette hardware, le data est stocké sur une hardware qui est parfois trop large pour juste le stockage. Donc vous avez des CPUs disponibles, une capacité RAM et ainsi de suite. Donc nous offrons ce que nous appelons le grid for apps, quelque chose d'utile pour déployer les tâches proche des données. Mais c'est assez hors de scop de la conférence actuelle. Nous sommes ici pour parler du stockage. Et je serais heureux de vous parler un peu plus de cela. Je suis assez loin du scop de la conférence actuelle, nous sommes ici pour parler de la stockage. Je serais heureux de vous parler un peu plus de ce sujet,

et je vous invite à en parler à la place de la plage qui sera présente dans le sonoma. Je suis un peu rapide, donc je suis terminé. Si vous avez des questions, je serais heureux d'en répondre. Et je vous invite à visiter le site web que nous affichons régulièrement. Est-ce que le stockage sans proxy est basé uniquement sur Kinetic ou est-ce basé sur un layer sous-contourné que vous mettez sur des disques rares? underlying layer that you put on raw disks? We are using in our proxy the protocol that is provided by the Kinectic group. So we developed a connector as we did for Backblaze. Backblaze, this is an HTTP connector with

authentication and so on. With Kinectic, that's quite the same. They provide the Google protocol buffers description, and we implemented this. C'est la même chose avec le kinétique. Ils offrent la description du buffer de protocoles Google et nous l'impliquons. Mais dans votre cas, direct signifie kinétique? Pour le kinétique, nous avons accès direct, pas de proxy. Oui, mais uniquement kinétique? Non, non, non, je reviendrai juste quelques slides plus tôt. La première solution, j'ai commencé avec ça,

car c'est la plus facile à présenter, mais la première fois que nous avons développé la solution, toutes les applications ont accès directement aux données. Votre librairie, votre librairie de software, all the applications access directly the data. Immediately. Your library, your software library, directly contacts all the drives. But this is the default case for the C API, for example. And the drive had a Linux file system on it? Linux file system exposed with the HTTP,

something like WebDAV. A restricted set from comme WebDAV. Un set restreint de l'opération WebDAV. Pouvoir mettre, émettre, émettre et... Et chaque objet resté sur le stock de la software OpenIO est un fichier régulier. Parce que j'ai mentionné le SQLite qui est utilisé pour toutes les directrices. On l'utilise, on le réplique par soi-même.

Tous les fichiers sont des fichiers de plainte sur des systèmes de fichiers. Et je sais qu'il y a eu une présentation juste avant qui parlait de la détection du système de fichiers sur l'architecture. Il y a probablement de bonnes raisons pour faire cela, mais dans notre histoire, il a été une bonne aide pour garder le système de fichiers, juste parce que vous avez tous les outils que l'administrateur peut gérer. Vous avez le replay avec les attributs extendés, donc il a toute l'opération pour mettre, mettre et ainsi de suite. Vous avez tous les...

Désolé? C'est un cas de utilisation différent de nous. Oui. Mais nous sommes vraiment heureux d'en avoir. sorry but we were really happy to have them ah sur la tête non non No other? No? So, I won't keep you in a closed room for longer if you don't have any questions.

Thank you for coming. Thank you for listening. I hope that it was interesting. Thanks for listening. If you have questions about the material presented in this podcast, be sure and join our developers mailing list by sending an email to developers-subscribe at sneha.org. Here you can ask questions and discuss this topic further with your peers in the developer community. For additional information about the Storage Developer Conference,

visit storagedeveloper.org.