> Pour ce qui est de ton parallèle avec 4KSTACK, je le trouve démesuré.
Tout à fait.
> pwc n'est qu'un driver qui n'écrase, afaik, rien au fonctionnement du noyau.
Il y a déjà eu une crainte de ce type dans le passé (durant le 2.4 et relatif aux systèmes de fichier en module mais j'ai oublié les détails). D'où les SYMBOL_EXPORT etc.
> Une fonction centrale de Linux n'a pas a appeler du code proprio. pwc est dans ce cas.
Ooops, ce n'est pas le cas de pwc. C'est un problème "classique" de respect de la GPL. Du code sous GPL est utilisé pour appeler une fonction proprio (qui n'est pas dans les exceptions Linux).
C'est tout.
Clairement, ce code doit être retiré de Linux. Ce qui a été fait. Le driver peut marché pour les utilisateurs qui n'utilisaient pas le parti proprio. Mais le mainteneur de pwc c'est énervé et a demande la suppression de tout le driver.
> il y a des utilisateurs du LL et que donc ils n'ont pas le droit de les ignorer.
C'est le ponpon ça !
Il y a un licence dans Linux qui est là pour les utilisateur et les développeurs respectent cette licence pour les utilisateurs.
Si l'utilisateur pense trouver son bonheur avec du proprio, alors qu'il utilise un OS proprio et fin de l'histoire pour l'utilisateur qui en a rien à foutre du LL.
Je suis utilisateur et _client_ de LL. Il est hors de question que le LL soit du logiciel proprio (cherchez l'erreur :-)). Point barre.
Je crois que beaucoup ne comprennent pas le problème.
Linux n'interdit pas d'_utiliser_ du proprio.
Linux (et Linus) interdit qu'on le modifie pour du proprio !
Linux (le coeur de l'OS, pas les drivers) ne veut pas être dépendant du proprio.
C'est aux développeurs de driver de suivre les specs de Linux et non l'inverse. C-à-d que ce n'est pas à un module proprio d'adapter Linux à ses besoins.
Un exemple, le passage à 4KSTACK.
Linux passe à 4KSTACK et NVidia doit adapter son driver. Linux n'a pas à rester en 8KSTACK car le driver NVidia ne marche pas en 4KSTACK.
Et si NVidia ne veut pas ou ne peut pas adapter son driver pour 4KSTACK alors :
1)- tant pis
2)- NVidia peut fournir un patch pour le noyau et l'utilisateur recompile le tout.
3)- Le modules NVidia gère le stack et écrase la gestion faite par défaut par Linux (techniquement ce n'est pas possible mais faisons "comme si").
NB, le 2) n'est pas possible avec un OS proprio. Alors arrêtons de considérer Linux comme intégriste alors qu'il est beaucoup plus "coolant" que tous les OS proprios et ce pour 0 ¤.
Le 3) est interdit par Linux car les fonctionnalités proches du coeur de Linux doivent être 100 % GPL. Une fonction centrale de Linux n'a pas a appeler du code proprio. pwc est dans ce cas.
> De toute manière pour moi un matériel sans spec, c'est un matériel inutile
C'est comme une voiture sans mode d'emploi. Tu serais obligé d'utiliser un driver (chauffeur) proprio pour utiliser ta voiture même si tu as envie de la conduire ou que tu ne veux plus du driver (chauffeur) car il conduit trop dangereusement à ton goût ou qu'il grille systématique les feux rouges et tu aimerais bien corriger ce "défaut".
> Mince, il va falloir le dire a NVidia, Connexant, ATI et pleins d'autres.
Va lire COPYING.modules des sources de Linux. Il y a une exception à la GPL et c'est pour ça que ces drivers proprios sont autorisés. Pour pwc c'est un autre problème.
> De toute facon je peux lier une appli complètement propriétaire aux bibliothèques standards en GPL.
Non. Et regarde bien, libc, etc sont sous LGPL et pas GPL.
Qt est GPL et tu ne peux pas faire d'appli proprio avec. Vas sur le site trolltech pour te renseigner.
> Le fait d'utiliser les APIs standards, les bibliothèques standards ou les appels standards d'un système ne peut pas constituer une violation de la GPL.
Le problème est de savoir qui utilise qui.
- C'est le noyau Linux qui utilise le driver ?
- C'est le driver qui utilise le noyau Linux ?
Pour un programme, on peut dire qu'un programme proprio utilise la libc mais on ne dit jamais l'inverse.
> Si ca n'était pas le cas on ne pourrait soit pas écrire de programmes GPL sous des OS propriétaires
C'est le programme sous GPL qui utilise des lib proprio et pas l'inverse. Donc pas de problème (tant que les libs sont "inhérentes au système").
> Dans la cas présent, il n'y a aucun code propriétaire dans le noyau. Just un hook pour charger un module, propriétaire certes, distribué séparément.
Pas seulement (de ce que j'ai compris).
Le drivers rend une fonction proprio public au noyau. C'est-à-dire que les autres parties du noyau peuvent appeler directement cette fonction (classique).
Mais il y a un patch qui appel une fonction proprio depuis le "coeur" GPL de Linux.
C'est comme si dans Linux il y avait :
read() {
if (!decrypt_data()) {
printf("permission denied") ;
}
}
> La GPL authorise des lib proprios a lier des applis GPL et des libs GPL a lier des applis ou ldes libs proprios a condition que les parties propriétaires soient inhérentes au système.
Ça marche si le noyau est proprio et le driver GPL. Mais là, c'est l'inverse.
Donc ça ne marche pas. Le noyau est plus "inhérent au système" qu'un driver.
> pasBill pasGates tu supportes pas un OS payant "à tous les étages" ?
>
> Plutot qu'essayer de lancer un troll n'ayant rien a voir avec le sujet, concentres toi sur le sujet en question.
Ce n'est pas hors sujet. Linux "dicte" son utilisation (avec EXPORT_SYMBOL, etc).
De plus Linux est une exception à la GPL qui permet d'utilise les modules binaires (dictature douce et ouverture au binaire incompatible avec la GPL).
Et encore "de plus", rien empêche le "Monsieur" de diffuser un patch pour le noyau si c'est nécessaire pour son driver.
Donc, il n'y a aucun problème s'il fait preuve d'un minimum de bonne volonté.
Avec MS, si tu (le développeur du driver et l'utilisateur) n'alignes pas le pognon, t'es "klonqué". Si tu as besoin de patcher le noyau, tu ne peux pas, etc...
Donc pasBill pasGates, tes leçons de morale aux développeurs de Linux (en les accusant presque d'intégristes/fanatiques du logiciel libre) sont très mal placées, et j'ai presque envis de t'inviter à te casser d'ici (pour ce thread seulement :-)).
> Ben justement, ils ont ete plutot incoherent en laissant faire pendant 3 ans
Non, non.
Depuis Linux 2.4 (milieu 2.4) et surtout 2.6, le mécanisme a été renforcé avec EXPORT_SYMBOL. Avant il fallait auditer manuellement le code et maintenant non.
> les seuls gens qui paient le prix
pasBill pasGates tu supportes pas un OS payant "à tous les étages" ?
Unix est de notre temps. MS-DOS non et pourtant il est moins vieux d'Unix.
Linux 2.6 est d'un temps rapproché du nôtre, par opposition à Unix qui est un ancien.
Unix est moderne (de notre temps).
Linux est moderne ET moderne (de notre temps ET non ancien).
> ext3 peut stocker les liens symboliques dans l'inode (ext2 aussi, d'ailleur c'est ext2 qui a implémenté ça en premier).
http://e2fsprogs.sourceforge.net/ext2intro.html(...) Ext2fs implements fast symbolic links. A fast symbolic link does not use any data block on the filesystem. The target name is not stored in a data block but in the inode itself.
ext3 c'est 16 To par partition et 4To par fichier (et pas 2Go !).
ext3 supporte les "fichier à trous" (ext2 aussi je crois).
ext3 peut stocker les liens symboliques dans l'inode (ext2 aussi, d'ailleur c'est ext2 qui a implémenté ça en premier).
Les gestions des bloques libres est un peu plus subtile que ce que décrit l'articles (il y a des groupes).
Pour "Gestion d'un grand nombre d'entrées de répertoire", c'est encore un peu plus subtile que ce qu'avance l'article. Si un répertoire a l'attribut 'I' (Indexed directory) il y a un index pour le répertoire. Il n'y a pas l'attribut 'I' pour tous les répertoires car ça ralentit (on voit ça aussi pour les bases de données). On peut utiliser fsck pour optimiser les répertoires et mettre automatiquement l'attribut 'I' aux répertoires suffisament importants pour que l'indexation améliore en performance.
NB : l'indexation est désactivée par défaut (pour l'ensemble du FS et par répertoire) ! Alors forcément, les benchs ne sont pas terribles (même les benchs qui prétendent utiliser htree).
Htree en action : http://lwn.net/Articles/14631/(...)
Ext3 n'est pas adapté aux petits fichiers ?
Pourquoi pas. Mais reiserfs avec le mode tail activé n'est pas rapide (il se fait "bouffé" en performance par ext3). Les benchs reiserfs sont en général avec notail (comme ext3).
> ext3 ne fait que rajouter la journalisation à l'antidéluvien système de fichier ext2
- et les attribut étendu.
- et ACL.
- et les "security label" (pour SeLinux)
- et les quota v2.
- et htree.
- et les fichiers de 4 To.
- et la journalisation la plus sûre actuellement tout système de fichier confondu (journalisation des meta-données et des données en même temps).
- et sparse_super
- et le resize à chaud
- e2fsprogs est maintenu par Theodore Ts'o et ça en fait une suite particuliairement fiable et sympatique (e2image, badblocks, dumpe2fs, debugfs, etc).
- et ... rien, mais rappelons que ça reste le système de fichier le plus fiable et que les bugs y sont rares. A utiliser les yeux fermés. Tout le monde ne peut pas en dire autant.
ext3 n'est pas mort. Pas pour cette année au moins.
En dépillant mon courrier de la mailing devel de Fedora, je suis tombé sur une discution sur reiserfs4 (forcément).
Et il y a eu le "pourquoi pas de reiserfs dans FC3 actuellement ?".
De: Russell Coker
Sujet: Re: reiser4
Date: Thu, 26 Aug 2004 00:29:18 +1000
SE Linux is a core feature of Fedora, and will be enabled by default in RHEL4.
Reiser 3 does not work with SE Linux and probably never will.
Reiser 4 has not yet been tested with SE Linux (AFAIK). I would not be surprised if testing revealed the same issues that we had with Reiser 3.
These issues are a reason for us to recommend against ReiserFS. We can only recommend and fully support features that work with all the major features of the distribution. If Reiser 4 can work well with SE Linux and get included in the kernel.org kernels then it can be supported as soon as we use one of the kernel.org kernels with ReiserFS included (which may be a while, we could be on 2.6.8 for a while).
De: Toshio
Sujet: reiserfs v3 and SELinux (Was Re: reiser4)
Date: Wed, 25 Aug 2004 11:02:05 -0400
What are the problems with Reiserfs 3? I thought the patches from Chris Mason of SuSE that went into the mainstream kernel in 2.6.7 enabled SELinux.
De: Stephen Smalley
Sujet: Re: reiserfs v3 and SELinux (Was Re: reiser4)
Date: Wed, 25 Aug 2004 11:13:59 -0400
Deadlock in the reiserfs xattr code when creating the internal directories and files used to store xattrs (when interacting with SELinux) and lack of a mechanism for informing SELinux that it shouldn't mediate access to the internal directories and files used by reiserfs to store its xattrs.
Parfois il suffit de pas grand chose pour rendre un FS inutilisable... Pour reiserfs v3 la solution n'est pas encore là. Pour que reiser4 soit en production, ça va être long.
> aucune concurrence ne viendra plus lui contester sa suprématie.
Dans le domaine des FS, rien est gagné d'avance et rien ne se gagne sur le papier pour Linux tant il y a de concurrence.
Les éloges pleuvaient pour reiserfs (v3) et ext3 était considéré par certains comme un projet mort-né. En effet, ext3 est sorti après reiserfs (c-à-d qu'il est venu contester la suprématie de reiserfs :-)).
On connait la suite de l'histoire jusqu'à Linux 2.6.9-rc1 (au jour d'aujourd'hui).
Si on regarde encore en arrière, il y a ext2. Tout le monde disait qu'avec ext2, ext avait poussé son dernier souffre. Pourtant il y a eu ext3. Il y aura peut-être ext4, les autres bossent aussi, etc.
Maintenant, un FS n'est pas seulement le format de stockage/organisation des données sur le disque dure pour y accéder rapidement. Il faut un haut niveau de fiabilité, supporter acl et selinux, ne pas avoir de problème de monté en charge, bien fonctionner avec lvm, etc.
On voit aussi la montée en puissance des clusters pour les systèmes de fichier.
Faut pas oublier qu'il n'y a pas que les FS avec plein de fichiers pour stocker des données. Il y a aussi les bases données et c'est plus efficace et plus souple lorsque les données sont bien organisées.
Reiserfs est peut-être le FS ultime aujourd'hui (quoiqu'il reste encore beaucoup de boulot apparament) mais pour demain, personne ne sait.
> Pour le challenge, je double la mise ;-)
T'avais pas déjà perdu ta chemise avec reiserfs v3 ?
Posté par 007 .
En réponse au journal Gamin.
Évalué à 2.
> - impossible de surveiller une hiérarchie de répertoires
Même problème pour une methode poll. Techniquement ça parait irréalisable. Le noyau bosse avec les inodes (ou vnode) mais pas avec les chemins. Y a aussi les cas subtile comme la cas du déplacement d'un répertoire qui sort de la "zone de surveillance". Ajoutes les "mount --bind" et autre goodies (lien physique entre répertoire) et c'est l'enfer.
> - grosse perte de perfs quand modifs fréquentes
Non :-)
C'est parce que ça marche très bien !
En mode poll (une fois par seconde par exemple), s'il y a 10 modifcations par secondes tu en rates 90 % !
Ça tombe bien, c'est ce que utilise Gamin (uniquement sous Linux).
> c'est ce qu'utilise ROX
Gamin est dans rawhide qui est sync Gnome 2.8.
Donc nautilus utilisera Dnotify sous Linux (via Gamin).
Avantage de Gamin, est d'être compatible Fam. Donc Gnome et KDE va utiliser Dnotify.
Fam n'est plus dans rawhide :-)
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par 007 . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 1.
Tout à fait.
> pwc n'est qu'un driver qui n'écrase, afaik, rien au fonctionnement du noyau.
Il y a déjà eu une crainte de ce type dans le passé (durant le 2.4 et relatif aux systèmes de fichier en module mais j'ai oublié les détails). D'où les SYMBOL_EXPORT etc.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 1.
non. Tout doit être GPL.
Puis techniquement il n'y a pas de hiérarchie de librairie (sauf l'ordre durant l'édition de lien). Donc il n'y a pas de "au-dessus de".
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par 007 . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 1.
Ooops, ce n'est pas le cas de pwc. C'est un problème "classique" de respect de la GPL. Du code sous GPL est utilisé pour appeler une fonction proprio (qui n'est pas dans les exceptions Linux).
C'est tout.
Clairement, ce code doit être retiré de Linux. Ce qui a été fait. Le driver peut marché pour les utilisateurs qui n'utilisaient pas le parti proprio. Mais le mainteneur de pwc c'est énervé et a demande la suppression de tout le driver.
[^] # Re: pas cool :/
Posté par 007 . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 5.
Tout à fait. Le but d'un OS libre, est d'être libre. Si en plus il domine toute la planette alors tant mieux. Mais la priorité N°1 est d'être libre.
Puis un OS Libre qui devient non libre pour dominer la planette à la place des OS non libre, quel intérêt ?
[^] # Re: pas cool :/
Posté par 007 . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 4.
C'est le ponpon ça !
Il y a un licence dans Linux qui est là pour les utilisateur et les développeurs respectent cette licence pour les utilisateurs.
Si l'utilisateur pense trouver son bonheur avec du proprio, alors qu'il utilise un OS proprio et fin de l'histoire pour l'utilisateur qui en a rien à foutre du LL.
Je suis utilisateur et _client_ de LL. Il est hors de question que le LL soit du logiciel proprio (cherchez l'erreur :-)). Point barre.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par 007 . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 5.
Je crois que beaucoup ne comprennent pas le problème.
Linux n'interdit pas d'_utiliser_ du proprio.
Linux (et Linus) interdit qu'on le modifie pour du proprio !
Linux (le coeur de l'OS, pas les drivers) ne veut pas être dépendant du proprio.
C'est aux développeurs de driver de suivre les specs de Linux et non l'inverse. C-à-d que ce n'est pas à un module proprio d'adapter Linux à ses besoins.
Un exemple, le passage à 4KSTACK.
Linux passe à 4KSTACK et NVidia doit adapter son driver. Linux n'a pas à rester en 8KSTACK car le driver NVidia ne marche pas en 4KSTACK.
Et si NVidia ne veut pas ou ne peut pas adapter son driver pour 4KSTACK alors :
1)- tant pis
2)- NVidia peut fournir un patch pour le noyau et l'utilisateur recompile le tout.
3)- Le modules NVidia gère le stack et écrase la gestion faite par défaut par Linux (techniquement ce n'est pas possible mais faisons "comme si").
NB, le 2) n'est pas possible avec un OS proprio. Alors arrêtons de considérer Linux comme intégriste alors qu'il est beaucoup plus "coolant" que tous les OS proprios et ce pour 0 ¤.
Le 3) est interdit par Linux car les fonctionnalités proches du coeur de Linux doivent être 100 % GPL. Une fonction centrale de Linux n'a pas a appeler du code proprio. pwc est dans ce cas.
[^] # Re: pas cool :/
Posté par 007 . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 1.
C'est comme une voiture sans mode d'emploi. Tu serais obligé d'utiliser un driver (chauffeur) proprio pour utiliser ta voiture même si tu as envie de la conduire ou que tu ne veux plus du driver (chauffeur) car il conduit trop dangereusement à ton goût ou qu'il grille systématique les feux rouges et tu aimerais bien corriger ce "défaut".
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 4.
Va lire COPYING.modules des sources de Linux. Il y a une exception à la GPL et c'est pour ça que ces drivers proprios sont autorisés. Pour pwc c'est un autre problème.
> De toute facon je peux lier une appli complètement propriétaire aux bibliothèques standards en GPL.
Non. Et regarde bien, libc, etc sont sous LGPL et pas GPL.
Qt est GPL et tu ne peux pas faire d'appli proprio avec. Vas sur le site trolltech pour te renseigner.
> Le fait d'utiliser les APIs standards, les bibliothèques standards ou les appels standards d'un système ne peut pas constituer une violation de la GPL.
Le problème est de savoir qui utilise qui.
- C'est le noyau Linux qui utilise le driver ?
- C'est le driver qui utilise le noyau Linux ?
Pour un programme, on peut dire qu'un programme proprio utilise la libc mais on ne dit jamais l'inverse.
> Si ca n'était pas le cas on ne pourrait soit pas écrire de programmes GPL sous des OS propriétaires
C'est le programme sous GPL qui utilise des lib proprio et pas l'inverse. Donc pas de problème (tant que les libs sont "inhérentes au système").
Linux est GPL et pas LGPL.
[^] # Re: Autre solution: hors kernel ?
Posté par 007 . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 4.
Pas seulement (de ce que j'ai compris).
Le drivers rend une fonction proprio public au noyau. C'est-à-dire que les autres parties du noyau peuvent appeler directement cette fonction (classique).
Mais il y a un patch qui appel une fonction proprio depuis le "coeur" GPL de Linux.
C'est comme si dans Linux il y avait :
read() {
if (!decrypt_data()) {
printf("permission denied") ;
}
}
Et que decrypt_data() était une fonction proprio.
[^] # Re: pas cool :/
Posté par 007 . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
Tu rèves. Linux a débuter sans 3d, sans, sans...
Il ne va pas s'écroulé car il y a un driver en moins.
[^] # Re: pas cool :/
Posté par 007 . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 3.
20 fois moins de développeurs et 3 à 4 fois plus de boulot, ils sont forts les développeurs Linux (à vu de pif, 1 dev Linux = 60 à 80 dev Windows).
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 0.
Ça marche si le noyau est proprio et le driver GPL. Mais là, c'est l'inverse.
Donc ça ne marche pas. Le noyau est plus "inhérent au système" qu'un driver.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à -8.
>
> Plutot qu'essayer de lancer un troll n'ayant rien a voir avec le sujet, concentres toi sur le sujet en question.
Ce n'est pas hors sujet. Linux "dicte" son utilisation (avec EXPORT_SYMBOL, etc).
De plus Linux est une exception à la GPL qui permet d'utilise les modules binaires (dictature douce et ouverture au binaire incompatible avec la GPL).
Et encore "de plus", rien empêche le "Monsieur" de diffuser un patch pour le noyau si c'est nécessaire pour son driver.
Donc, il n'y a aucun problème s'il fait preuve d'un minimum de bonne volonté.
Avec MS, si tu (le développeur du driver et l'utilisateur) n'alignes pas le pognon, t'es "klonqué". Si tu as besoin de patcher le noyau, tu ne peux pas, etc...
Donc pasBill pasGates, tes leçons de morale aux développeurs de Linux (en les accusant presque d'intégristes/fanatiques du logiciel libre) sont très mal placées, et j'ai presque envis de t'inviter à te casser d'ici (pour ce thread seulement :-)).
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à -1.
Non, non.
Depuis Linux 2.4 (milieu 2.4) et surtout 2.6, le mécanisme a été renforcé avec EXPORT_SYMBOL. Avant il fallait auditer manuellement le code et maintenant non.
> les seuls gens qui paient le prix
pasBill pasGates tu supportes pas un OS payant "à tous les étages" ?
[^] # Re: Conseils ?
Posté par 007 . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 2.
La voiture et le metro ne sont pas des modes de transport modernes ?
http://colet.uchicago.edu/cgi-bin/dico1look.pl?strippedhw=MODERNE(...)
La dernière définition de Académie française :
Qui est soit de notre temps, soit d'un temps plus ou moins rapproché du nôtre, par opposition à Antique, à ancien.
Unix est de notre temps. MS-DOS non et pourtant il est moins vieux d'Unix.
Linux 2.6 est d'un temps rapproché du nôtre, par opposition à Unix qui est un ancien.
Unix est moderne (de notre temps).
Linux est moderne ET moderne (de notre temps ET non ancien).
# Re:
Posté par 007 . En réponse au message petite erreur de boot. Évalué à 2.
title Windows
rootnoverify (hd0,0)
chainloader +1
[^] # Re: Conseils ?
Posté par 007 . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 2.
On va de surprise en surprise. C'est une traduction d'un article qu'on trouve dans un linux Gazette de juillet 2000 ! plus de 4 ans !
http://www.linuxgazette.com/issue55/index.html(...)
[^] # Re: Conseils ?
Posté par 007 . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 1.
http://e2fsprogs.sourceforge.net/ext2intro.html(...)
Ext2fs implements fast symbolic links. A fast symbolic link does not use any data block on the filesystem. The target name is not stored in a data block but in the inode itself.
[^] # Re: Conseils ?
Posté par 007 . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 4.
N'est absolument pas à jour et parfois faux.
ext3 c'est 16 To par partition et 4To par fichier (et pas 2Go !).
ext3 supporte les "fichier à trous" (ext2 aussi je crois).
ext3 peut stocker les liens symboliques dans l'inode (ext2 aussi, d'ailleur c'est ext2 qui a implémenté ça en premier).
Les gestions des bloques libres est un peu plus subtile que ce que décrit l'articles (il y a des groupes).
Pour "Gestion d'un grand nombre d'entrées de répertoire", c'est encore un peu plus subtile que ce qu'avance l'article. Si un répertoire a l'attribut 'I' (Indexed directory) il y a un index pour le répertoire. Il n'y a pas l'attribut 'I' pour tous les répertoires car ça ralentit (on voit ça aussi pour les bases de données). On peut utiliser fsck pour optimiser les répertoires et mettre automatiquement l'attribut 'I' aux répertoires suffisament importants pour que l'indexation améliore en performance.
NB : l'indexation est désactivée par défaut (pour l'ensemble du FS et par répertoire) ! Alors forcément, les benchs ne sont pas terribles (même les benchs qui prétendent utiliser htree).
Htree en action : http://lwn.net/Articles/14631/(...)
Ext3 n'est pas adapté aux petits fichiers ?
Pourquoi pas. Mais reiserfs avec le mode tail activé n'est pas rapide (il se fait "bouffé" en performance par ext3). Les benchs reiserfs sont en général avec notail (comme ext3).
> ext3 ne fait que rajouter la journalisation à l'antidéluvien système de fichier ext2
- et les attribut étendu.
- et ACL.
- et les "security label" (pour SeLinux)
- et les quota v2.
- et htree.
- et les fichiers de 4 To.
- et la journalisation la plus sûre actuellement tout système de fichier confondu (journalisation des meta-données et des données en même temps).
- et sparse_super
- et le resize à chaud
- e2fsprogs est maintenu par Theodore Ts'o et ça en fait une suite particuliairement fiable et sympatique (e2image, badblocks, dumpe2fs, debugfs, etc).
- et ... rien, mais rappelons que ça reste le système de fichier le plus fiable et que les bugs y sont rares. A utiliser les yeux fermés. Tout le monde ne peut pas en dire autant.
ext3 n'est pas mort. Pas pour cette année au moins.
[^] # Re: Innovations...
Posté par 007 . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 1.
En dépillant mon courrier de la mailing devel de Fedora, je suis tombé sur une discution sur reiserfs4 (forcément).
Et il y a eu le "pourquoi pas de reiserfs dans FC3 actuellement ?".
De: Russell Coker
Sujet: Re: reiser4
Date: Thu, 26 Aug 2004 00:29:18 +1000
SE Linux is a core feature of Fedora, and will be enabled by default in RHEL4.
Reiser 3 does not work with SE Linux and probably never will.
Reiser 4 has not yet been tested with SE Linux (AFAIK). I would not be surprised if testing revealed the same issues that we had with Reiser 3.
These issues are a reason for us to recommend against ReiserFS. We can only recommend and fully support features that work with all the major features of the distribution. If Reiser 4 can work well with SE Linux and get included in the kernel.org kernels then it can be supported as soon as we use one of the kernel.org kernels with ReiserFS included (which may be a while, we could be on 2.6.8 for a while).
De: Toshio
Sujet: reiserfs v3 and SELinux (Was Re: reiser4)
Date: Wed, 25 Aug 2004 11:02:05 -0400
What are the problems with Reiserfs 3? I thought the patches from Chris Mason of SuSE that went into the mainstream kernel in 2.6.7 enabled SELinux.
De: Stephen Smalley
Sujet: Re: reiserfs v3 and SELinux (Was Re: reiser4)
Date: Wed, 25 Aug 2004 11:13:59 -0400
Deadlock in the reiserfs xattr code when creating the internal directories and files used to store xattrs (when interacting with SELinux) and lack of a mechanism for informing SELinux that it shouldn't mediate access to the internal directories and files used by reiserfs to store its xattrs.
Parfois il suffit de pas grand chose pour rendre un FS inutilisable... Pour reiserfs v3 la solution n'est pas encore là. Pour que reiser4 soit en production, ça va être long.
Pas facile la vie de système de fichier :-)
[^] # Re: Innovations...
Posté par 007 . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 2.
Dans le domaine des FS, rien est gagné d'avance et rien ne se gagne sur le papier pour Linux tant il y a de concurrence.
Les éloges pleuvaient pour reiserfs (v3) et ext3 était considéré par certains comme un projet mort-né. En effet, ext3 est sorti après reiserfs (c-à-d qu'il est venu contester la suprématie de reiserfs :-)).
On connait la suite de l'histoire jusqu'à Linux 2.6.9-rc1 (au jour d'aujourd'hui).
Si on regarde encore en arrière, il y a ext2. Tout le monde disait qu'avec ext2, ext avait poussé son dernier souffre. Pourtant il y a eu ext3. Il y aura peut-être ext4, les autres bossent aussi, etc.
Maintenant, un FS n'est pas seulement le format de stockage/organisation des données sur le disque dure pour y accéder rapidement. Il faut un haut niveau de fiabilité, supporter acl et selinux, ne pas avoir de problème de monté en charge, bien fonctionner avec lvm, etc.
On voit aussi la montée en puissance des clusters pour les systèmes de fichier.
Faut pas oublier qu'il n'y a pas que les FS avec plein de fichiers pour stocker des données. Il y a aussi les bases données et c'est plus efficace et plus souple lorsque les données sont bien organisées.
Reiserfs est peut-être le FS ultime aujourd'hui (quoiqu'il reste encore beaucoup de boulot apparament) mais pour demain, personne ne sait.
> Pour le challenge, je double la mise ;-)
T'avais pas déjà perdu ta chemise avec reiserfs v3 ?
[^] # Re: DNotify
Posté par 007 . En réponse au journal Gamin. Évalué à 2.
Même problème pour une methode poll. Techniquement ça parait irréalisable. Le noyau bosse avec les inodes (ou vnode) mais pas avec les chemins. Y a aussi les cas subtile comme la cas du déplacement d'un répertoire qui sort de la "zone de surveillance". Ajoutes les "mount --bind" et autre goodies (lien physique entre répertoire) et c'est l'enfer.
> - grosse perte de perfs quand modifs fréquentes
Non :-)
C'est parce que ça marche très bien !
En mode poll (une fois par seconde par exemple), s'il y a 10 modifcations par secondes tu en rates 90 % !
[^] # Re: Conseils ?
Posté par 007 . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 1.
Une fourchette est moderne.
MS-DOS n'est pas moderne.
Unix est moderne depuis 30 ans :-)
[^] # Re: DNotify
Posté par 007 . En réponse au journal Gamin. Évalué à 2.
Et Gamin. Espérons que KDE ne va pas encore gueuler car KDE va dépendre gamin qui dépend de glib-2.
[^] # Re: DNotify
Posté par 007 . En réponse au journal Gamin. Évalué à 4.
Tu parles de ça :
http://www.devchannel.org/devtoolschannel/04/05/13/2146252.shtml(...) (chercher dnotify dans la page)
Ça tombe bien, c'est ce que utilise Gamin (uniquement sous Linux).
> c'est ce qu'utilise ROX
Gamin est dans rawhide qui est sync Gnome 2.8.
Donc nautilus utilisera Dnotify sous Linux (via Gamin).
Avantage de Gamin, est d'être compatible Fam. Donc Gnome et KDE va utiliser Dnotify.
Fam n'est plus dans rawhide :-)