P.S: Ce n'est pas les seuls à travailler dessus: EMC Inc. (Server), Sun Microsystems (Solaris & Java client/server), Network Appliance (Server), Hummingbird Inc. (Windows/NT Client and Server)
P.S.2: Si vous avez le temps, allez jeter un coup d'oeil sur 2 autres projets de l'equipe: Linux Scalability et NFS Client Performance.
Aller plus loin
- Le RFC 3010 décrivant la norme (prévoyez un bon toner si vous l'imprimez) (7 clics)
- La page de l'implémentation Linux/OpenBSD (6 clics)
- Le code (2 clics)
# Enfin
Posté par David Bober (site web personnel) . Évalué à -3.
Le reve :)
[moua]
# Enfin !
Posté par Thomas Nemeth (site web personnel) . Évalué à 10.
Les grandes avancées sont surtout la sécurité améliorée et la rapidité.
Étant donné que le code est déjà en cours de création pour Linux et OpenBSD, une meilleure interaction entre ces 2 OS sera vraiment améliorée (déjà que c'est assez sympa comme ça :)
Bref, vivement que ce soit stabilisé et dans le noyau !
[^] # Enfin
Posté par kalahann . Évalué à -4.
NFS pue quand même un peu, encore que sous solaris ça marche plutôt bien.
Bah, plus qu'à attendre la norme v5 pour que la v4 soit stable!
[^] # Re: Enfin !
Posté par gilles renault (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: Enfin !
Posté par Thomas Nemeth (site web personnel) . Évalué à 10.
Il faut tout de même savoir que ça ne s'improvise pas : autant il est facile avec les distributions actuelle de mettreen oeuvre un serveur NFS, autant pour améliorer les perfs, il vaut mieux lire les docs et savoir ce qu'on fait...
# Stabilité (et correction ortho)
Posté par Jar Jar Binks (site web personnel) . Évalué à 10.
Espérons que ce nouveau projet attirera des codeurs et qu'il sera mieux optimisé, ça serait une grande chance pour linux (de nombreux serveurs NFS sont encore sous Solaris, réputé plus stable dans ce domaine et souvent conforme à sa réputation (enfin, ces temps-ci ça empire donc ça serait bien d'avoir une vraie implémentation libre fonctionnelle)).
Et une correction orthographique : on dit agressif, avec un seul g.
[^] # Re: Stabilité (et correction ortho)
Posté par Alphonse Oncle . Évalué à 5.
Tout a fait. J'ai recontre pas mal de pb avec nfs en milieu heterogene.
Sinon nfs plus stable sur solaris, forcement vu que c'est sun qui a fait nfs.
[^] # ca veut rien dire...
Posté par Le_Maudit Aime . Évalué à -2.
et hop -1
[^] # Re: ca veut rien dire...
Posté par Sébastien Munch . Évalué à 5.
'fin c'est ce que j'ai lu ...
[^] # oui oui...
Posté par Le_Maudit Aime . Évalué à -1.
[^] # Re: Stabilité
Posté par Anonyme . Évalué à -3.
[^] # Re: Stabilité
Posté par Anonyme . Évalué à -3.
[^] # Re: Stabilité
Posté par Anonyme . Évalué à 9.
mouais, enfin, y a des baies de disques sécurisées qui fonctionnent très bien et qui sont accedées via NFS (celles de Network Appliance justement) ; elles sont prévues pour être intégrées dans des environnement critiques... (chez Proxad, entre autres, y en a plein...)
[^] # Re: Stabilité
Posté par Pascal Terjan (site web personnel) . Évalué à -6.
<troll>Ca explique pas mal de choses ;)</troll>
[^] # Re: Stabilité
Posté par Olivier Jeannet . Évalué à 9.
En tous cas, si NFS n'était pas utilisable sur des serveurs critiques, ça se saurait... J'ai utilisé pendant 2 ans du NFS sous Sun de façon intensive et ça marche bien.
[^] # Re: Stabilité
Posté par matiasf . Évalué à 3.
[^] # Re: Stabilité
Posté par Anonyme . Évalué à 4.
En clair, la baie de disques joue le rôle de serveur NFS, par contre, je sais pas quel OS (embarqué, je suppose) est intégré.
Les débits constatés sont d'ailleurs meilleurs qu'avec du SCSI, par contre, je sais pas ce que ça donne face à de baies en Fiber channel.
[^] # Re: Stabilité
Posté par Olivier Jeannet . Évalué à 4.
En fait ce n'est pas vraiment comparable, dans un cas il s'agit d'un protocole pour accéder à un système de fichier distant (qui peut être un sur simple disque IDE ou une baie RAID complète), de l'autre un bus physique pour connecter un (ou plusieurs) disque(s) à une unité centrale (via une carte contrôleur).
Les débits constatés sont d'ailleurs meilleurs qu'avec du SCSI
Tu es sûr de toi ? Car le SCSI peut monter à 80 ou 160 Mo/s (vitesse max de l'U2W et de l'Ultra160), alors qu'avec de l'Ethernet 100 (pour le NFS) on plafonne à 10-12 Mo/s, et de plus les latences ne sont pas les mêmes du fait de l'aspect RPC du NFS. Je ne connais pas les chiffres réels avec de l'Ethernet Gigabit.
[^] # Re: Stabilité
Posté par Nicolas Boulay (site web personnel) . Évalué à -1.
nicO
"La première sécurité est la liberté"
[^] # Bug dacode
Posté par Anonyme . Évalué à -6.
-1
[^] # Re: Bug dacode
Posté par Netsabes . Évalué à -3.
Pis retester, aussi, en te mettant à -1.
Et mettre le tout sur http://sourceforge.net/tracker/?func=add&group_id=6997&atid(...) merci :)
Hop, -1, OT.
[^] # Re: Bug dacode
Posté par Anonyme . Évalué à -4.
Mon bug : http://glandium.free.fr/sshot12.jpg(...)
Je le mets aussi sur sourceforge...
[^] # Re: Bug dacode
Posté par Netsabes . Évalué à -2.
Il faut donc retester pour toi :)
Ca me semble quand même très (très très) bizarre comme bug. Tu serais pas bourr*hips* et tu aurais pas appuy*hips* sur le lien [ Répondre ] du dessus ?
Non enfin, je demande, tout le monde sait que daCode ne peut pas être buggé :)
-1, tout ça.
[^] # Re: Bug dacode
Posté par Anonyme . Évalué à -3.
Et non, je ne suis pas bourr*hips* et j'ai bien répondu au bon post, étant donné que j'ai fait un copier-coller d'un bout de phrase au moment où j'ai fait le post.
Cela dit, j'avais déjà remarqué ce genre de manifestation, mais pas fait remarqué...
[^] # Re: Bug dacode
Posté par Netsabes . Évalué à -2.
J'avais corrigé un bug très con qui pouvait causer ça (enfin, qui faisait un nouveau thread au lieu d'une réponse), qui venait de l'écrasage des variables dans l'URI. Ca devrait quand même être réglé depuis bien 2 mois, et surtout, ça n'arrivait généralement que quand on se loggait/déloggait sur la page d'écriture d'un post.
Si c'est récent, ça arrive depuis la dernière update ou pas ?
-1, tout ça.
[^] # Re: Bug dacode
Posté par Anonyme . Évalué à -3.
En tout cas, le comportement est aléatoire, puisque ça marche correctement la plupart du temps...
-1 tout ça.
[^] # Re: Stabilité (et correction ortho)
Posté par Julien CARTIGNY (site web personnel) . Évalué à 10.
Concernant la stabilité, les equipes travaillant sur les différentes implémentations se réunissent réguliérement pour voir le fonctionement en commun.
De plmus, c'est SUN qui sponsorise le développement de NFSv4 pour Linux et OpenBSD: véritable bonne volonté ?
Par contre, actuellement seul un codeur (assisté de 2 étudiants) travaille sur ce projet. Il faudra donc attendre un peu une réelle ouverture du code pour esperer une bonne stabilité ("nobody is perfect).
P.S: BUG Dacode ? j'ai dû réecrire ce post car malgré le message de confirmation he n'ai rien vu apparaître à l'écran.
[^] # Re: Stabilité (et correction ortho)
Posté par Jar Jar Binks (site web personnel) . Évalué à 7.
S'il s'agit du code noyau, c'est pour les clients, non ? On comprend bien que Sun a intérêt à voir se répandre des clients NFS 4 pour pouvoir vendre les serveurs correspondants. Par contre, ça m'étonnerait qu'ils aident au développement du serveur...
[^] # Re: Stabilité (et correction ortho)
Posté par Julien CARTIGNY (site web personnel) . Évalué à 9.
"The next milestone of this project is to produce an IETF compliant NFS version 4 client and server running in the Linux kernel by June 30, 2001"
[^] # Re: Stabilité (et correction ortho)
Posté par Benoît Sibaud (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.