La libsafe et les outils d'immunix (http://immunix.org(...)) arretent brutalement l'exécution d'un programme lorsqu'un buffer overflow classique est détecté. Ca évite d'exploiter les overflows pour faire des bétises, mais c'est un peu radical, et ça ne remplace pas un environnement et un code sécurisé.
Quant à ton point de vue sur Perl... je le partage entierement. Ne serait-ce-que parce que tout ce qu'il est possible de faire en PHP est refaisable en Perl, alors que l'inverse n'est pas vrai (et Lingua::Romana::Perligata n'existe pas en PHP) . Le seul intéret que je trouve à PHP est la gestion des sessions. Mais bref, ne relançons pas ce genre de débat. Le meilleur langage est de toutes façons celui que l'on connait le mieux, quel qu'il soit !
Dans tous les cas, on passe par SSH ce qui permet d'une part de crypter les données, mais aussi d'utiliser les clefs RSA ou DSA pour ne jamais avoir à taper de mot de passe. 'scp' devient aussi simple que 'cp', et peut s'utiliser dans des scripts, par exemple pour automatiser la mise à jour de plusieurs machines distantes.
Hum, à vrai dire, en dehors du C, du C++, du forth et de l'assembleur, aucun langage ne permet d'écrire n'importe où en mémoire, surtout involontairement.
Les exceptions systématiques et le securitymanager de Java sont effectivement très efficaces contre ce genre de bourdes. Mais ce ne sont que des barrières qui ne transforment pas miraculeusement un mauvais code en un code sûr et solide. Simplement, les conséquences d'un bogue sont différentes. Ca va davantage se traduire par un déni de service que par l'exécution de code arbitraire (porte joyeusement ouverte par un buffer overflow) .
Perl est aussi un bon choix pour placer des barrières autour d'un code pas forcément très sûr, en particulier grâce à l'excellent mode "taint".
Tu peux effectuer ta connexion SSH, puis taper :
tcpserver 0 ftp /usr/local/sbin/pure-ftpd &
Et voilà, ton serveur FTP tourne et il n'y a aucune différence avec un "standalone".
Les super-serveurs comme tcpserver, g2s et xinetd possèdent de quoi prendre correctement en charge les connexions, maintenir des fichiers d'historique, effectuer du filtrage IP, ... Bref, tout ce qui se passe entre le moment où un client demande une connexion et celui où la session commence réellement avec le serveur.
Tout les serveurs "standalone" doivent réimplémenter tout ça. Et la configuration de ces éléments redondants se fait pourtant chaque fois d'une façon totalement différente d'un logiciel à l'autre.
Pure-FTPd n'a actuellement pas de mode "standalone" pour cette raison : il doit rester simple, petit, et se concentrer sur le protocole FTP et non la négociations des connexions, que d'autres logiciels font très bien. Si je commence à y ajouter la gestion de bases de données CDB (pour le filtrage IP, comme TCPServer), on va obtenir un produit plus lourd. Et ceux qui n'utilisent pas le filtrage en subiraient quand meme les conséquences.
Et même au niveau sécurité, c'est intéressant de séparer chaque tâche. Ainsi, g2s/xinetd/tcpserver/rlinetd/etc... sont audités de leur coté, et les serveurs qu'ils lancent, d'un autre côté. Si un bug ou une faille de sécurité se produit, on ne perd pas de temps à la localiser ("zut, ça a planté... il y a un D.O.S... est-ce-qu'il vient des fonctions qui acceptent les connexions TCP et du filtrage IP ? Est-ce dans les fonctions qui demandent le login du client FTP ?" - Le problème ne se pose pas si ces parties sont séparées) .
D'autre part... Avoir un mode "standalone" pour des logiciels comme Apache et Proftpd est intéressant car ils possèdent un fichier de configuration avec une syntaxe complexe. Le déchiffrer prend du temps. S'il faut le déchiffrer à chaque fois qu'un client se connecte (en mode non-standalone), c'est forcément plus lent que si ces fichiers sont analysés une fois pour toutes.
Maintenant, dans le cas de Pure-FTPd, le démarrage est immédiat : les options sont en ligne de commande, le cache des uid/gid se construit dynamiquement, et les serveurs virtuels ne sont détectés que s'ils sont réellement utilisés. Donc lancer Pure-FTPd en standalone ou à partir d'un super-serveur revient sensiblement au même pour les performances.
Cela dit, il y aura peut-etre effectivement un mode standalone avant la version 1.0, mais uniquement pour avoir une architecture encore plus blindée niveau sécurité. En gros, il y aura un "serveur de bind" qui n'aura aucune capacité (au sens des "capabilities" du noyau Linux) si ce n'est celle d'ouvrir des connexions sur des ports privilégiés et de passer les descripteurs au réel serveur. Résultat : *aucune* partie du serveur ne tournera sous l'identité "root" (la cause de tous les soucis des autres logiciels) .
Il existe un petit serveur FTP sous Linux codé par Troll-Tech (oui, ceux qui font Qt) : Troll-FTPd.
Tout petit ("no bloat"), extremement stable, très sécurisé (jamais le moindre trou découvert), simple à mettre en oeuvre...
Malheureusement l'auteur n'a plus le temps de vraiment s'y consacrer.
Je viens donc de prendre le relais, et le serveur se nomme désormais Pure-FTPd.
*** N'UTILISEZ PAS REISERFS SUR LES ORDINATEURS PORTABLES ***
Pourquoi donc ? Ce serait bien pratique pour éviter les fsck lorsque les batteries ont lâché un peu tôt !
Oui mais voilà : lorsque les applications ne font plus aucun accès au disque, ReiserFS en profite pour rééquilibrer l'arbre, synchroniser le journal, et plus tard le déplacer.
Conséquence positive : pendant les périodes d'inactivité, le filesystem s'optimise.
Conséquence négative : le disque dur "gratte" davantage qu'avec Ext2. L'autonomie des notebooks sur batteries est donc réduite.
Bref sur un portable, utilisez Ext2 et noflushd ( http://noflushd.sourceforge.net(...) ) . N'hésitez pas non plus à compiler vos applis dans un ramdisk (le filesystem swapfs est pratique pour ça) : c'est plus rapide et le disque dur peut rester en veille. Et sur un portable, montez absolument vos partitions en noatime,nodiratime.
Le RAID n'est pas géré au niveau des filesystems, mais de la VFS. Matériel ou logiciel il ne pose donc pas de problème à priori avec ReiserFS.
Si tu veux concaténer plusieurs disques durs, passe par LVM (http://www.sistina.com(...)) . LVM a de toutes façons plein d'avantages.
Il y a par contre une grosse limitation actuellement : on peut étendre une partition ReiserFS, mais pas la réduire. La réduction nécessite d'implémenter de quoi compacter l'arbre, ce qui n'a pas encore été réalisé.
Le hachage permet d'accéder rapidement à un fichier lorsque l'on connaît son nom. Il ne se destine pas à accélerer la consultation du contenu des répertoires. Pour accélérer le find dans tous les cas le plus efficace reste 'locate' !
Je ne suis plus employé par Hans Reiser (euh... d'ailleurs je cherche un boulot...) . J'ai donc la liberté de pouvoir parler objectivement. Le but des messages était simplement d'informer un peu les gens de ce qu'était réellement ReiserFS au delà d'un simple systeme journalisé. Je ne pense pas avoir pris position ni forcé qui que ce soit à installer ReiserFS. Tux2, XFS et Intermezzo sont aussi à suivre de près.
Monte ton /tmp en notails,noatime,nodiratime et compile là-dedans.
D'autre part les performances dépendent aussi... de l'occupation des partitions. Eh oui, quand une partition est pleine à craquer, quelque soit le filesystem, il faut commencer à jongler pour organiser correctement ses données. Ca vient peut-etre de ça, le fait que la compilation soit plus lente désormais chez toi.
Moralité : si vous avez un gros disque dur, avec de l'espace à gogo : faites plusieurs partitions (ne serait-ce-que pour des raisons de fiabilité : un /tmp qui merdouille ne va pas corrompre /home) .
Si vous etes plutot juste en place, faites une seule grosse partition !
Pour que ton code soit intégré à ReiserFS tu dois écrire une lettre disant en gros "j'autorise l'inclusion de mon code. Le résultat appartient à Hans Reiser qui peut le modifier, le vendre ou en faire ce qu'il veut".
Ceci pour éviter un coup dans le dos qu'on lui a fait dans ses débuts.
Les quotas fonctionnent sous ReiserFS. Quelqu'un a fait un patch pour cela. Mais ce patch ne peut etre intégré dans ReiserFS pour le moment pour des problèmes juridiques (le gars doit faxer un papier à Brook, l'avocat de Hans, et ne l'a pas fait) .
Compiler le kernel avec l'option Sysrq (c'est dans la partie "Debuggage") est aussi une bonne idée. En cas de gauffrage, on peut généralement taper Sysrq-S (synchronisation des durs), Sysrq-I (kill de tous les processus), Sysrq-U (passage en read-only de tous les disques), Sysrq-B (reboot), etc....
C'est aussi un bon moyen d'éviter les fsck en ext2 !
Attention : en cas de reboot suite à une coupure de courant... Tu ne perds pas la structure de tes fichiers. Par contre, tu peux perdre les données qui étaient dans le cache. Et tu peux perdre aussi... un peu d'espace disque.
Eh oui... la relecture du journal ne peut être parfaite : si on était en train de réorganiser un bout de l'arbre au moment du crash, il se peut que des blocs attribués (d'après la liste des blocs libres -bitmap-) ne fassent pourtant plus partie de l'arbre... Voilà pourquoi ReiserFS n'a aucun intéret sous Zindoz !
ReiserFS 3.6 (noyaux 2.4) est un peu plus performant que ReiserFS 3.5 (noyaux 2.2) . Si vous avez formatté vos partitions en ReiserFS lors de l'install d'une SuSE ou d'une Mandrake, il y a des chances pour que vous soyez en ReiserFS 3.5 . Il ne suffit pas de passer au noyau 2.4 pour avoir les performances de ReiserFS 3.6 . Vous pourrez relire vos données, mais c'est en quelque sorte une "émulation" : vos données ne seront pas au nouveau format du 3.6 .
Pour convertir au nouveau format, montez vos partitions avec l'option "conv" . Dès ce moment, les NOUVEAUX fichiers seront au NOUVEAU format. Bref, pour tout convertir : backup et restauration totale....
L'intéret majeur du nouveau format est le support des fichiers dont la taille est sur 64 bits (hum, en fait 60 bits... c'est une limitation de la VFS pas de ReiserFS, mais c'est déjà gigantesque) .
Les programmeurs de XFS sont très bons (comme tous ceux de SGI en général) . Je ne doute pas que leur portage sous Linux sera réussi et que les performances seront un cran au dessus des autres. Sans compter les quelques particularités du système, comme le débit garanti ("je veux au moins tant de Mo/seconde sur ce fichier, quelque soient les autres opérations faites sur le dur" - génial pour le son et la vidéo) .
Mais aujourd'hui, ReiserFS est beaucoup plus stable et avancé. Et demain, les objectifs de l'un et de l'autre ne sont pas les memes.
La version actuelle de ReiserFS (au niveau de l'organisation physique des
données) est la 3. D'une version majeure a l'autre, beaucoup de choses sont
remises en question. En bref : n'esperez pas relire vos partitions ReiserFS
4 sous un kernel avec ReiserFS 3. Dans l'autre sens, il est possible que ça
fonctionne, Hans Reiser s'étant engagé auprès d'Alan Cox à supporter ce
format ad vitam eternam. En pratique.... on verra. Mais pas de panique
cependant : ReiserFS 4 n'est prévu que pour Linux 2.6 (ce qui veut dire
qu'en pratique ce sera encore plus tard) .
A court terme, ReiserFS 3 (TROIS) va implémenter les wandering logs. Pour
l'instant, le journal est situé à un endroit fixe du disque, choisi lors du
formattage du dur. En dehors des problèmes de déplacement de la tete de
lecture, ce n'est pas très fiable d'écrire sans arret dans la meme zone du
disque dur. On augmente considérablement ses chances d'obtenir des
badblocks. Et des badblocks dans le journal, ce n'est pas bon du tout.
Les wandering logs consistent à avoir un journal qui se déplace dans
différentes zones du disque (si possible près des données les plus accédées) .
Toujours à court terme, il y a des chances pour que les disques durs à
problème (badblocks) soient un peu mieux gérés que maintenant. Actuellement,
en cas de badblock, ReiserFS espere que le disque va faire un remapping
transparent des secteurs. Certains disques SCSI le font. Mais si ce n'est
pas le cas... hum... pour l'instant vous risquez de paumer des données.
Toutes les données de ReiserFS sont stockées sous la forme d'un arbre : si
on coupe une branche, il devient difficile de retrouver tout ce qui se
trouvait en dessous. En fait, Hans Reiser dit souvent "si on commence à
avoir des badblocks, le disque dur ne va pas tarder à lacher de toutes
façons, donc il faut changer de dur". Mais bon, tout le monde le saoule pour
qu'un traitement des badblocs soit tout de meme implémenté. A mon avis, ce
sera fait rapidement, dès que Chris et Vladimir auront un peu de temps, et
après les wandering logs.
Bon sinon pour la v4 ... Quelques idées ont été évoquées et validées. Mais
rien n'est sur, et aucune implémentation n'a débuté :
- Les snapshots à la Netapp.
- Un filesystem distribué en réseau, pour remplacer les croulants NFS et
Coda (projet mort, les développeurs planchent sur Intermezzo qui est
actuellement inutilisable, ils testent juste des concepts avec une premiere
approche en Perl) . L'idée serait éventuellement d'envisager un partenariat
avec GFS (Global Filesystem, excellent projet, mais pas hyper rapide au
niveau de l'écriture physique. ReiserFS serait un bon complément) .
- Plus de limitation pour les collisions avec les valeurs de hachage. Je
n'ai pas envie de m'étaler là-dessus, mais en gros, à chaque nom de fichier
est associé une clef. Si un répertoire contient 127 fois la même clef, on ne
peut plus créer de nouveau fichier avec cette clef. Xuan a proposé une
solution pour y remédier (en gros, on crée un nouveau tableau de 127 clefs) .
- Les plug-ins !!! Enfin !!!
Voilà... je vais m'arreter là... fatigué....
Babouilles à tous, j'espere que ces quelques lignes vous auront éclairé
sur les objectifs de ReiserFS !
[^] # Re: Pure-FTPd
Posté par j . En réponse à la dépêche Un virus attaque les machines RedHat. Évalué à 1.
[^] # Re: Zont qu'à programmer en Java !
Posté par j . En réponse à la dépêche Un virus attaque les machines RedHat. Évalué à 1.
Quant à ton point de vue sur Perl... je le partage entierement. Ne serait-ce-que parce que tout ce qu'il est possible de faire en PHP est refaisable en Perl, alors que l'inverse n'est pas vrai (et Lingua::Romana::Perligata n'existe pas en PHP) . Le seul intéret que je trouve à PHP est la gestion des sessions. Mais bref, ne relançons pas ce genre de débat. Le meilleur langage est de toutes façons celui que l'on connait le mieux, quel qu'il soit !
[^] # Re: Pure-FTPd
Posté par j . En réponse à la dépêche Un virus attaque les machines RedHat. Évalué à 1.
scp fichier1 fichier2 fichier3 login@machi.ne:/tmp
scp -r login@machi.ne:/usr/src/linux /var/import
scp login@machi.ne:/home/j/images/\*.jpg /tmp
Dans tous les cas, on passe par SSH ce qui permet d'une part de crypter les données, mais aussi d'utiliser les clefs RSA ou DSA pour ne jamais avoir à taper de mot de passe. 'scp' devient aussi simple que 'cp', et peut s'utiliser dans des scripts, par exemple pour automatiser la mise à jour de plusieurs machines distantes.
[^] # Re: Zont qu'à programmer en Java !
Posté par j . En réponse à la dépêche Un virus attaque les machines RedHat. Évalué à 1.
Les exceptions systématiques et le securitymanager de Java sont effectivement très efficaces contre ce genre de bourdes. Mais ce ne sont que des barrières qui ne transforment pas miraculeusement un mauvais code en un code sûr et solide. Simplement, les conséquences d'un bogue sont différentes. Ca va davantage se traduire par un déni de service que par l'exécution de code arbitraire (porte joyeusement ouverte par un buffer overflow) .
Perl est aussi un bon choix pour placer des barrières autour d'un code pas forcément très sûr, en particulier grâce à l'excellent mode "taint".
[^] # Re: Pure-FTPd
Posté par j . En réponse à la dépêche Un virus attaque les machines RedHat. Évalué à 1.
tcpserver 0 ftp /usr/local/sbin/pure-ftpd &
Et voilà, ton serveur FTP tourne et il n'y a aucune différence avec un "standalone".
Les super-serveurs comme tcpserver, g2s et xinetd possèdent de quoi prendre correctement en charge les connexions, maintenir des fichiers d'historique, effectuer du filtrage IP, ... Bref, tout ce qui se passe entre le moment où un client demande une connexion et celui où la session commence réellement avec le serveur.
Tout les serveurs "standalone" doivent réimplémenter tout ça. Et la configuration de ces éléments redondants se fait pourtant chaque fois d'une façon totalement différente d'un logiciel à l'autre.
Pure-FTPd n'a actuellement pas de mode "standalone" pour cette raison : il doit rester simple, petit, et se concentrer sur le protocole FTP et non la négociations des connexions, que d'autres logiciels font très bien. Si je commence à y ajouter la gestion de bases de données CDB (pour le filtrage IP, comme TCPServer), on va obtenir un produit plus lourd. Et ceux qui n'utilisent pas le filtrage en subiraient quand meme les conséquences.
Et même au niveau sécurité, c'est intéressant de séparer chaque tâche. Ainsi, g2s/xinetd/tcpserver/rlinetd/etc... sont audités de leur coté, et les serveurs qu'ils lancent, d'un autre côté. Si un bug ou une faille de sécurité se produit, on ne perd pas de temps à la localiser ("zut, ça a planté... il y a un D.O.S... est-ce-qu'il vient des fonctions qui acceptent les connexions TCP et du filtrage IP ? Est-ce dans les fonctions qui demandent le login du client FTP ?" - Le problème ne se pose pas si ces parties sont séparées) .
D'autre part... Avoir un mode "standalone" pour des logiciels comme Apache et Proftpd est intéressant car ils possèdent un fichier de configuration avec une syntaxe complexe. Le déchiffrer prend du temps. S'il faut le déchiffrer à chaque fois qu'un client se connecte (en mode non-standalone), c'est forcément plus lent que si ces fichiers sont analysés une fois pour toutes.
Maintenant, dans le cas de Pure-FTPd, le démarrage est immédiat : les options sont en ligne de commande, le cache des uid/gid se construit dynamiquement, et les serveurs virtuels ne sont détectés que s'ils sont réellement utilisés. Donc lancer Pure-FTPd en standalone ou à partir d'un super-serveur revient sensiblement au même pour les performances.
Cela dit, il y aura peut-etre effectivement un mode standalone avant la version 1.0, mais uniquement pour avoir une architecture encore plus blindée niveau sécurité. En gros, il y aura un "serveur de bind" qui n'aura aucune capacité (au sens des "capabilities" du noyau Linux) si ce n'est celle d'ouvrir des connexions sur des ports privilégiés et de passer les descripteurs au réel serveur. Résultat : *aucune* partie du serveur ne tournera sous l'identité "root" (la cause de tous les soucis des autres logiciels) .
[^] # Re: Attention danger !
Posté par j . En réponse à la dépêche Un virus attaque les machines RedHat. Évalué à 1.
# Pure-FTPd
Posté par j . En réponse à la dépêche Un virus attaque les machines RedHat. Évalué à 1.
Tout petit ("no bloat"), extremement stable, très sécurisé (jamais le moindre trou découvert), simple à mettre en oeuvre...
Malheureusement l'auteur n'a plus le temps de vraiment s'y consacrer.
Je viens donc de prendre le relais, et le serveur se nomme désormais Pure-FTPd.
Vous le trouverez sur http://www.sourceforge.net/projects/pureftpd(...) ainsi que sur http://www.jedi.claranet.fr(...)
Jetez-y un coup d'oeil, surtout qu'il est réellement dédié à Linux.
-Jedi.
[^] # Re: Performances
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 1.
[^] # Re: vitesse d'un find?
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 1.
[^] # Re: Notebooks
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 1.
# Notebooks
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 1.
*** N'UTILISEZ PAS REISERFS SUR LES ORDINATEURS PORTABLES ***
Pourquoi donc ? Ce serait bien pratique pour éviter les fsck lorsque les batteries ont lâché un peu tôt !
Oui mais voilà : lorsque les applications ne font plus aucun accès au disque, ReiserFS en profite pour rééquilibrer l'arbre, synchroniser le journal, et plus tard le déplacer.
Conséquence positive : pendant les périodes d'inactivité, le filesystem s'optimise.
Conséquence négative : le disque dur "gratte" davantage qu'avec Ext2. L'autonomie des notebooks sur batteries est donc réduite.
Bref sur un portable, utilisez Ext2 et noflushd ( http://noflushd.sourceforge.net(...) ) . N'hésitez pas non plus à compiler vos applis dans un ramdisk (le filesystem swapfs est pratique pour ça) : c'est plus rapide et le disque dur peut rester en veille. Et sur un portable, montez absolument vos partitions en noatime,nodiratime.
-Jedi.
[^] # Re: Et avec le RAID logiciel?
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 1.
Si tu veux concaténer plusieurs disques durs, passe par LVM (http://www.sistina.com(...)) . LVM a de toutes façons plein d'avantages.
Il y a par contre une grosse limitation actuellement : on peut étendre une partition ReiserFS, mais pas la réduire. La réduction nécessite d'implémenter de quoi compacter l'arbre, ce qui n'a pas encore été réalisé.
-Jedi. ( pub: http://www.rtchat.com(...) )
[^] # Re: vitesse d'un find?
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 1.
[^] # Re: REISERFS - Dernier épisode (snif)
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 1.
-Jedi.
[^] # Re: REISERFS - Dernier épisode (snif)
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 1.
D'autre part les performances dépendent aussi... de l'occupation des partitions. Eh oui, quand une partition est pleine à craquer, quelque soit le filesystem, il faut commencer à jongler pour organiser correctement ses données. Ca vient peut-etre de ça, le fait que la compilation soit plus lente désormais chez toi.
Moralité : si vous avez un gros disque dur, avec de l'espace à gogo : faites plusieurs partitions (ne serait-ce-que pour des raisons de fiabilité : un /tmp qui merdouille ne va pas corrompre /home) .
Si vous etes plutot juste en place, faites une seule grosse partition !
-Jedi.
[^] # Re: REISERFS - Dernier épisode (snif)
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 1.
[^] # Re: Avantage - Désavantages...
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 1.
Ceci pour éviter un coup dans le dos qu'on lui a fait dans ses débuts.
[^] # Re: ben....
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 1.
[^] # Re: Avantage - Désavantages...
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 1.
-Jedi.
[^] # Re: Avantage
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 1.
C'est aussi un bon moyen d'éviter les fsck en ext2 !
-Jedi.
[^] # Re: Ca marche
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 1.
Eh oui... la relecture du journal ne peut être parfaite : si on était en train de réorganiser un bout de l'arbre au moment du crash, il se peut que des blocs attribués (d'après la liste des blocs libres -bitmap-) ne fassent pourtant plus partie de l'arbre... Voilà pourquoi ReiserFS n'a aucun intéret sous Zindoz !
-Jedi.
[^] # Re: système de fichiers journalisés
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 1.
Pour convertir au nouveau format, montez vos partitions avec l'option "conv" . Dès ce moment, les NOUVEAUX fichiers seront au NOUVEAU format. Bref, pour tout convertir : backup et restauration totale....
L'intéret majeur du nouveau format est le support des fichiers dont la taille est sur 64 bits (hum, en fait 60 bits... c'est une limitation de la VFS pas de ReiserFS, mais c'est déjà gigantesque) .
-Jedi.
[^] # Re: Avantage
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 1.
Mais aujourd'hui, ReiserFS est beaucoup plus stable et avancé. Et demain, les objectifs de l'un et de l'autre ne sont pas les memes.
[^] # Re: REISERFS : Episode 2
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 1.
http://www.innominate.org/~phillips/tux2(...)
# REISERFS - Dernier épisode (snif)
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 5.
*** REISERFS DEMAIN ***
La version actuelle de ReiserFS (au niveau de l'organisation physique des
données) est la 3. D'une version majeure a l'autre, beaucoup de choses sont
remises en question. En bref : n'esperez pas relire vos partitions ReiserFS
4 sous un kernel avec ReiserFS 3. Dans l'autre sens, il est possible que ça
fonctionne, Hans Reiser s'étant engagé auprès d'Alan Cox à supporter ce
format ad vitam eternam. En pratique.... on verra. Mais pas de panique
cependant : ReiserFS 4 n'est prévu que pour Linux 2.6 (ce qui veut dire
qu'en pratique ce sera encore plus tard) .
A court terme, ReiserFS 3 (TROIS) va implémenter les wandering logs. Pour
l'instant, le journal est situé à un endroit fixe du disque, choisi lors du
formattage du dur. En dehors des problèmes de déplacement de la tete de
lecture, ce n'est pas très fiable d'écrire sans arret dans la meme zone du
disque dur. On augmente considérablement ses chances d'obtenir des
badblocks. Et des badblocks dans le journal, ce n'est pas bon du tout.
Les wandering logs consistent à avoir un journal qui se déplace dans
différentes zones du disque (si possible près des données les plus accédées) .
Toujours à court terme, il y a des chances pour que les disques durs à
problème (badblocks) soient un peu mieux gérés que maintenant. Actuellement,
en cas de badblock, ReiserFS espere que le disque va faire un remapping
transparent des secteurs. Certains disques SCSI le font. Mais si ce n'est
pas le cas... hum... pour l'instant vous risquez de paumer des données.
Toutes les données de ReiserFS sont stockées sous la forme d'un arbre : si
on coupe une branche, il devient difficile de retrouver tout ce qui se
trouvait en dessous. En fait, Hans Reiser dit souvent "si on commence à
avoir des badblocks, le disque dur ne va pas tarder à lacher de toutes
façons, donc il faut changer de dur". Mais bon, tout le monde le saoule pour
qu'un traitement des badblocs soit tout de meme implémenté. A mon avis, ce
sera fait rapidement, dès que Chris et Vladimir auront un peu de temps, et
après les wandering logs.
Bon sinon pour la v4 ... Quelques idées ont été évoquées et validées. Mais
rien n'est sur, et aucune implémentation n'a débuté :
- Les snapshots à la Netapp.
- Un filesystem distribué en réseau, pour remplacer les croulants NFS et
Coda (projet mort, les développeurs planchent sur Intermezzo qui est
actuellement inutilisable, ils testent juste des concepts avec une premiere
approche en Perl) . L'idée serait éventuellement d'envisager un partenariat
avec GFS (Global Filesystem, excellent projet, mais pas hyper rapide au
niveau de l'écriture physique. ReiserFS serait un bon complément) .
- Plus de limitation pour les collisions avec les valeurs de hachage. Je
n'ai pas envie de m'étaler là-dessus, mais en gros, à chaque nom de fichier
est associé une clef. Si un répertoire contient 127 fois la même clef, on ne
peut plus créer de nouveau fichier avec cette clef. Xuan a proposé une
solution pour y remédier (en gros, on crée un nouveau tableau de 127 clefs) .
- Les plug-ins !!! Enfin !!!
Voilà... je vais m'arreter là... fatigué....
Babouilles à tous, j'espere que ces quelques lignes vous auront éclairé
sur les objectifs de ReiserFS !
-Jedi.