Ça fait depuis bien longtemps qu'on est dans le registre "j'avance et tu recule, je tourne à droite et je regarde à gauche..." avec gstreamer et KDE.
Maintenant ça devient pénible.
> MAS comme ARTS est un framework multimedia(audio seulement) et un serveur de son. Il fait les deux à la fois!
Une grosse différence entre MAS et ARTS est que MAS marche aussi via réseau et il faut considérer que tu ne peux pas modifier la partie serveur (comme pour X11).
Le serveur ARTS, est pour _un_ utilisateur (celui qui vient de se logguer). A l'instar de X11, le serveur MAS est pour toutes les applis clientes qui se connectent au serveur. Le serveur MAS n'est pas lancé lorsque tu te logguent mais à l'initialisation d'X11 (ce n'est pas encore fait mais au final c'est comme ça que le serveur sera lancé).
Oui il y aura des codecs et quelques effets rudimentaires dans MAS.
Pourquoi des codecs ?
Car il faut envoyer et recevoir le son via réseau et donc compresser le son est une bonne idée. Actuellement, il n'y a que le codec mp3 dans MAS ! Et ce codec ne permet pas de coder en mp3 mais uniquement de lire.
Il y aura aussi AC5.1, ...
Il y aura un mixer évolué (c'est sur le serveur qu'il y a la carte son...).
Il y aura sûrement des features qui ne sont pas liées à un serveur de son.
X11 offre aussi des facilités et il y a eu beaucoup d'applis faitent uniquement avec libX11. Ça n'en fait pas un framework pour faire des applis graphiques.
Ce n'est pas parce que X11 affiche mon DVD que c'est un framework multimedia.
> pour Kde
Tout est là...
1 - Gstreamer utilise glib.
2 - Gstreamer à l'origine cible Gnome.
3 - Dans Gstreamer il y a 'G'.
Trois "bonnes" raisons pour KDE de ne pas utiliser Gstreamer.
Mais pour la lecture de video ça va être rigolo. Gstreamer récupère le flux video et audio (forcément), mais KDE va demander à Gstreamer de ne pas envoyer le flux audio à MAS (ce que peut faire Gstreamer). KDE va récuper le flux audio pour l'envoyer à MAS.
Un peu bordélique.
Ou KDE vire Gstreamer et utilise Xine qui utilisera MAS (bref comme Gstreamer le fait).
Quoiqu'il en soit, pour la video MAS ne sera utilisé que comme un serveur son.
> TU AVAIS TORD
KDE ne pense pas la même chose que Gnome (ou plus spécifiquement Gstreamer) qui considère MAS comme un serveur de son.
KDE ne voit pas MAS et Gstreamer de la même façon que freedesktop :
* GStreamer is a streaming media framework.
* Media Application Server™ (MAS®) is a network transparent streaming media server.
Je ne veux pas me battre avec toi (utilisateur kde?) :
KDE a raison, les autres tords (dont moi) et ils ne font que troller.
Il y a quelques temps, KDE se plaignait de la lenteur de Gstreamer à intégrer leur patch.
Je dis : que KDE n'utilise pas Gstreamer alors. Comme ça on aura la paix.
C'est pour ça qu'il y a rc.local.
rc.local est vide à l'origine.
Oops, c'est faux, il y "touch /var/lock/subsys/local" :-)
Il y aura peut-être un .rpmnew pour rc.local mais tu peux l'ignorer (sûrement une mise à jour du commentaire dans le fichier). À moins que "touch /var/lock/subsys/local" soit buggé ou présente un trou de sécurité :-)
Et tu peux toujours faire un script dans /etc/rc.d/init.d/ (ala Debian).
Tu trouveras toujours un cas où il faut modifier rc.sysinit. Mais franchement, regardes les forums d'aide ou les mailings et tu verras qu'on ne propose pratiquement jamais de modifier rc.sysinit.
Et si c'était le cas, Red Hat utiliserait un système type Debian.
Ils ne sont pas cons :-)
J'image bien que ce n'est pas fait au hazard...
Mais la compréhension est moins "fulgurante" qu'avec un "bête" rc.sysinit.
Ceci dit, je m'en fous :-)
rc.sysinit (tel qu'il est fait par Red Hat) ou /etc/rcS.d/ ne change rien ou presque.
Par contre, j'apprécie d'avoir /etc/httpd/conf.d/ ou /etc/ld.so.conf.d/ etc.
Ça évite d'éditer /etc/httpd/conf/httpd.conf etc. Mais /etc/rc.d/rc.sysinit n'est _jamais_ édité (par les scripts d'installation de rpm par exemple).
Je ne dis pas que Debian à tord.
J'essaie, mais je n'y arrive pas, d'expliquer pourquoi Red Hat fait comme ça.
Pour un usage classique (je ne parle pas d'embarqué qui de toute manière a des scripts spécifiques, ou de la secrétaire qui boot son PC i486 à 33Mhz 10 fois par jours).
> Si, la clarté
Pour un script de 860 lignes dont le niveau maxi d'indentation est de 5 !
Fichtre.
> un autre avec 80 fonctions de 10 lignes dans 30 fichiers, lequel est le plus clair ? :)
C'est vraiment pas évident.
Le "Red Hat touch" :
fichier init :
# init usb
(...)
# init ide
(...)
Avec le "Red Hat touch", c'est évident. Tout est excécuté dans un ordre, une fois et c'est tout.
Avec le "Debian touch", si je regarde le fichier init_usb, je ne sais pas s'il doit être appelé avant ou après init_ide, je ne sais pas s'il peut être appelé plusieurs fois, etc...
Si un programme n'est pas modulaire (comme le rc.sysinit de RedHat) il est inutile de faire croire qu'il est (surtout pour 800 lignes).
The ext3 have almost a perfect record with the write cache off: I have run over 300 cycles on the two drives and only had two corrupted lines in the output files. So out of 600 total cycles on the two drives there were only two lines with bad data, I think that is a pretty good record.
None of the other journaling file systems have come anywhere near this performance. After 3 or 4 power cycles, ReiserFS became corrupted to the point that the system would not boot up (the fsck failed and the bootup stopped there). XFS never got corrupted to the point it wouldn't boot, but with approximately 100 power cycles on each drive, one drive had 73 corrupted lines and the other had 82. With JFS after 15 power cycles one of the drives was corrupted and the system would no longer boot up (fsck failed again).
Enfin, et ce point est important bien que souvent ignoré, Red Hat a des compétences en ext3.
S'il y a des problèmes avec xfs, RedHat n'a pas forcément les compétences en interne pour corriger ou expertiser rapidement le problème.
Si tu veux du reiserfs, prend du SuSE, ils ont les compétence. Pour ext3, regardes du côté de Red Hat. Pour XFS, install Irix :-)
Un distributeur ne peut pas avoir des compétences sur tous les FS. Surtout qu'avec toutes les combinaisons (FS/lvm/raid/acl/nfs/GFS) ça devient très très vite l'enfer pour tout tester si tu supports tous les FS (ext3, xfs, jfs, reiser3, reiser4, etc).
> mon fs favoris, c'est XFS ;)
Le mien, ext3. Principalement car il est fiable, il me suffit, il est en standard avec ma distrib (Je n'ai pas à récupérer de patch, etc) et j'ai pas envie de me prendre la tête pour gagne 0,2 % en perfo ou place disque.
Je suis fainéant et j'ai jamais pris le temps de tester les différents FS dispos sous Linux.
> Et quand j'etais etudiant en IUT, j'ai commencé la programmation en mettant tout dans le meme fichier. Mes profs m'ont vite fait comprendre que ce n'est pas la bonne méthode.
Gros ou petit fichier, ce n'est pas le point ici.
Red Hat veux que tout soit initialisé au niveau hard.
Red Hat ne veux pas qu'une partie seulement ou quelques parties au chois de l'utilisateur soient initialisées.
Tu peux critiquer cette politique si tu veux.
Si redhat fait :
include boot.usb
include boot.udev
etc
et que les fichiers sont toujours inclus (cas c'est la volonté de RedHat), ça ne change rien par rapport à un "gros" fichier.
Par contre, pour les services, Red Hat veut laisser plus de souplesse et là il y a plusieurs fichiers.
Mais faire plusieurs fichiers au-lieu d'un gros, sans un réelle objectif de modularité, n'a aucun intérêt. C'est le cas pour le rc.sysinit de RedHat :-) et donc c'est fort logiciquement qu'il n'y a qu'un seul fichier.
Là tu n'y es pas :-)
Désolé.
La seul optimisation que tu peux trouver à éditer rc.sysinit est en vitesse de boot. Rien d'autre. rc.sysinit ne lance pas de processus résidents etc (sauf cas exceptionnel).
De plus, s'il est possible de déplacer une partie de rc.sysinit dans /etc/init.d sans perte de fonctionnalité, ça sera fait. Mais, par exemple, déplacer l'init de usb dans /etc/init.d est une mauvaise idée (comment faire un fsck par exemple). Idem pour raid.
Afin, RedHat/Fedora est une distribution qui "just works" (enfin, ils essaient :-)).
Donc rc.sysinit doit toujours initialiser tout les périphériques de façon minimum (usb, raid, etc). Sinon ça veut dire que lorsque tu ajoutes une partition (récupérée d'une autre machine), la partition ne sera pas vue s'il n'y a pas le paquet (ou autre) sysinit_usb ou firewire ou...
Juste par curiosité, pourquoi tu veux éditer /etc/rc.d/rc.sysinit à part pour avoir un boot très très légèrement plus rapide.
> Mandrake a peur de s'eloigner de RedHat. C'est l'argument choc que l'on m'a sortie
Pour reiserfs, il y a de grosses différences entre RedHat et Mandrake :
- RedHat/Fedora ne propose pas de façon claire reiserfs. Il faut savoir qu'il faut taper "linux reiserfs" à l'invite de l'installation sinon reiserfs n'est pas proposé (idem pour jfs, xfs, etc).
- reiserfs n'est pas supporté par RHEL. Si t'es emmerdé par reiserfs, inutile d'appeler le support RH.
- RedHat (moins pour Fedora) ne fait pas l'effort de patché leur noyau avec les derniers bugfix de reiserfs. Il y a que ext3 qui est "soigné".
> Devoir encore formatter de manière particulière sa partition pour avoir un nombre fixe d'inodes est une restriction qui commence à se faire pesante
Ouais. Mais c'est rare les gens qui sont limités par la valeur par défaut lors du formatage.
En gros, une partition de 20 Go donne 2 500 000 inode !
J'ai jamais vu sur un forum quelqu'un demander à augmenter le nombre d'inode d'une partion ext3...
> quand tu dois travailler dans un environnement avec des arborescences profondes et un grand nombre de fichiers.
man tune2fs :
dir_index
Use hashed b-trees to speed up lookups in large
directories.
sparse_super
Limit the number of backup superblocks to save space
on large filesystems.
sparse_super évite d'avoir 40 superblocks à mettre à jour. La profondeur ne change rien puisque le répertoire est repéré par l'inode.
man e2fsck :
-D
Optimize directories in filesystem. This option causes e2fsck
to try to optimize all directories, either by reindexing them if
the filesystem supports directory indexing, or by sorting and
compressing directories for smaller directories, or for filesys-
tems using traditional linear directories.
> Je trouve également pesant de perdre aux alentours de 10% de ma partition pour le journal.
Où tu as vu ça ?
Exemple avec une partition de 120 Go :
# cat /proc/partitions
major minor #blocks name
9 0 120372992 md0
# df /dev/md0
Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
/dev/md0 120111456 70477292 49634164 59% /
# bc
(120372992-120111456)/120372992*100 .21727132
261536 blocks de 1k pour le FS uniquement.
Un peu plus de 0,2 % de blocs de 1K utilisé pour la gestion d'ext3. Imaginons qu'au pire de l'utilisation je monte à 0,5 % (faut beaucoup d'imagination...).
man mke2fs :
size=journal-size
Create an internal journal (i.e., stored inside the
filesystem) of size journal-size megabytes. The
size of the journal must be at least 1024 filesystem
blocks (i.e., 1MB if using 1k blocks, 4MB if using
4k blocks, etc.) and may be no more than 102,400
filesystem blocks.
On est très très loin de tes 10 %.
Tu ne confond pas avec les "Reserved blocks" qui est configurable avec "tune2fs|mke2fs -m" ? Pour les "Reserved blocks", c'est 10 % par défaut.
Utilises "tune2fs|mke2fs -m 0 /dev/partition".
> Nous ne sommes plus à lépoque de Rémi Card créant ext2.
ext2 n'a pas été fait dans l'urgence. Avant il y avait ext et encore avant minix.
Tiens, j'y pense. Pourquoi les gens pour critiquer ext3 de fs pas moderne font référence à ext2 alors qu'il pourrait faire référence à ext qui est encore plus vieu :-)
Astuce :
Comme récupérer un fichier qui n'a plus de lien mais est encore ouvert par un processus ?
Simple, exemple :
$ cd /proc/359/fd
$ ll 6
lr-x------ 1 me me 64 aoû 25 16:22 6 -> /tmp/fichier (deleted)
$ cp 6 /tmp/fichier
Un petit exemple pour clarifier :
[me@here tmp]$ ll -h -i
total 2,6G
16134 -rw-r--r-- 1 me me 2,6G aoû 25 07:59 gros_fichier
[me@here tmp]$ df .
Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
/dev/md0 120111456 71511120 48600336 60% /
[me@here tmp]$ ln gros_fichier gros_fichier_ln1
[me@here tmp]$ ln gros_fichier gros_fichier_ln2
[me@here tmp]$ ln gros_fichier gros_fichier_ln3
[me@here tmp]$ ln gros_fichier gros_fichier_ln4
[me@here tmp]$ ln gros_fichier gros_fichier_ln5
[me@here tmp]$ ll -h -i
total 16G
16134 -rw-r--r-- 6 me me 2,6G aoû 25 07:59 gros_fichier
16134 -rw-r--r-- 6 me me 2,6G aoû 25 07:59 gros_fichier_ln1
16134 -rw-r--r-- 6 me me 2,6G aoû 25 07:59 gros_fichier_ln2
16134 -rw-r--r-- 6 me me 2,6G aoû 25 07:59 gros_fichier_ln3
16134 -rw-r--r-- 6 me me 2,6G aoû 25 07:59 gros_fichier_ln4
16134 -rw-r--r-- 6 me me 2,6G aoû 25 07:59 gros_fichier_ln5
[me@here tmp]$ df .
Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
/dev/md0 120111456 71511120 48600336 60% /
Aucun espace disque de consommée en plus.
C'est toujours le même fichier (l'inode 16134) et le nombre de lien physique du inode/fichier est passé de 1 à 6. Le inode/fichier est supprimé lorsque le nombre de lien physique passe à 0.
D'ailleur il n'y a pas de commande (appel système) pour supprimer un fichier sous Unix !
Il y a unlink() qui supprime un lien physique. Si le nombre de lien physique passe à zero, le fichier est "enfin" supprimé.
Les liens physiques ne marchent pas entre deux périphériques (ou partitions) différents.
C'est pour celà qu'il y a les liens symboliques :-)
man ln :
DESCRIPTION
Sous Unix, il existe deux types de ‘liens’ entre fichiers, que l’on
nomme généralement liens matériels (ou physiques) et liens symboliques
(ou logiques).
Un lien matériel est simplement une manière de nommer un fichier. Un
fichier peut avoir plusieurs noms. Un fichier n’est effacé réellement
que lorsque son dernier nom est supprimé. Le nombre de noms d’un
fichier est indiqué par la commande ls(1). Il n’y a pas de notion de
nom ‘original’ : tous les noms d’un fichier ont exactement la même
importance. Tous les noms d’un fichier se trouvent généralement - mais
ce n’est pas obligatoire - dans le système de fichiers contenant les
données du fichier.
Un lien symbolique est d’un tout autre genre. Il s’agit d’un petit
fichier spécial, qui contient un chemin d’accès. Ainsi un lien symbol-
ique peut pointer vers un système de fichier différent de celui qui
l’accueille. Il peut également pointer, grâce à NFS, vers un système
de fichiers appartenant à une autre machine. Enfin, un lien symbolique
ne pointe pas nécessairement vers un fichier existant.
Je parle du bouton reset et pas de <ctrl><alt><sup> .
Avec le bouton reset, le cpu est figé de suite (idem pour les périphériques pci, etc) et il n'y a pas vidage du cache.
Par contre le cache des disques (au niveau des disques et pas de l'OS) est écrit.
Mais c'est aussi comme ça en cas de coupure de courrant. Les disques ont un minimum d'autonomie pour assurer l'écriture (sauf les très mauvais disque).
*******************************************************************
This is an EXPERIMENTAL version of fsck.reiser4. Read README first.
*******************************************************************
Et dans le README :
FSCK.REISER4 WARNING
This is an experimental software yet, MAKE A BACKUP BEFORE USING IT! Do not
run rebuild unless something is broken. If you have bad sectors on a drive
it is usually a bad idea to continue using it. Then you probably should get
a working hard drive, copy the file system from the bad drive to the good
one -- dd_rescue is a good tool for that -- and only then run this program.
Ça fait penser au début de reiserfs V3 où la meilleur méthode pour corriger un fs corrompu a longtemps été mkreiserfs...
Un fs sans fsck correcte ne mérite pas d'être numéroté 1.0.0.
> Mwai, il n'empeche que ext3 n'a rien d'un fs moderne
???
On peut dire qu'Unix n'a rien d'un OS moderne si on commence avec ce type d'argument.
ext3 a toutes les fonctionnalités ou presque.
lvm => ça marche
acl => ça marche
selinux => ça marche
cluster type gfs => ça marche
fiabilité => excellente
Il lui manque ces petits trucs (mais techniquement difficile à réaliser) qui permet de gagner 2 à 3 % en perfo en usage typique et à fiabilité équivalente. Le problème des benchs est qu'ils sont rarement fait à niveau de fiabilité équivalent. Ils sont concentrés sur les performances.
> Je trouve juste dommage que redhat/mdk restent bloqués sur ce fs juste pour une histoire de compatibilité ext2.
Red Hat a largement démontré qu'ils n'hésite pas à ignorer la compatibilité si ça va dans le bon sens.
Red Hat est dédié serveur et leurs utilisateurs sont plus proches des administrateurs que des hobbystes.
La compatibilité c'est bien, mais s'il faut casser la compatibilité pour avoir meilleur, il le feront.
> redhat aime bien ext3 pour des raison techniques mais qui ne concerne que la journalisation.
Pas que ça. RedHat a aussi une floppée de tests (fiabilité, tenue en charge, fonctionnalité, etc) et ext3 les passes tous ce qui n'est pas le cas de reiserfs. Parole d'Alan Cox. NB : vrai pour Linux 2.4, j'ai pas d'info pour Linux 2.6.
Si Reiserfs4 est techniquement excellent (et aussi dans la pratique :-)), complet (un fsck qui roxor aussi), performant, fiable, etc, ajoutes 6/12 mois pour que le tout soit rock solide et Red Hat utilisera reiserfs.
Puis il faut arrêter de pointer Red Hat comme un méchant qui ne veut pas utiliser reiserfs. ext3 est aussi le fs le plus utilisé par les développeurs Linux.
En gros, Red Hat fait comme la majorité des développeurs.
J'ai lu beaucoup de bien de reiserfs v4. Si c'est pas du pipo publicitaire (comme reiserfs v3), ou pour draguer les filles en discothèque, reiserfs v4 passera devant ext3 (toutes distributions confondues).
Que je sache, Linux est un logiciel libre et ce sont les meilleurs solutions qui s'imposent. Les préférences de Red Hat ne change rien à ça (au moins à long terme).
SVP : arrêtez avec le complot RedHat/mdk (Pourquoi tu parles de mdk?) pour empêcher l'"envol" de reiserfs.
On y voit rien !
Ext3FS :
1) Taille maximale du système de fichiers : 4 To
2) Taille de blocs : De 1 à 4 Ko
3) Taille maximale de fichier : 2 Go
1) => faux. je n'ai pas d'url sous la main mais c'est faux au moins pour Linux 2.6
2) => vrai ! bravo !
3) => faux.
Voilà un de mes répertoires (j'enregistre les JO :-) :
$ ll -h
total 14G
-rw-r--r-- 1 me me 1,5G aoû 24 21:00 JO_2004-08-24-19:52.avi
-rw-r--r-- 1 me me 2,5G aoû 24 23:00 JO_2004-08-24-21:00.avi
-rw-r--r-- 1 me me 1,8G aoû 25 00:00 JO_2004-08-24-23:00.avi
-rw-r--r-- 1 me me 4,6G aoû 25 02:00 JO_2004-08-25-00:00.avi
-rw-r--r-- 1 me me 3,8G aoû 25 03:29 JO_2004-08-25-02:00.avi
C'est qu'un exemple...
Sinon ext3 supporte aussi htree. Il faut faire :
tune2fs -O dir_index /dev/...
e2fsck -f -D /dev/...
Je veux bien admettre qu'ext3 n'est pas la F1 des FS, mais ce n'est pas une 2CV.
De plus il a presque toutes les fonctionnalités et en rock solide. Il ne manque que le resize à chaud et c'est actuellement en phase de debug (dans FC2 et ça marche :-)).
> Je me souviens avoir senti la différence de perfs entre les deux en faisant des grosses compiles (gros avantage pour reseirfs3, parceque c'est justement sur les nombreux accès à des petits fichiers qu'il excelle).
Pour les compilations ?
Tu es sûre ?
Quand je compile, tout est en cache et le cpu est utilisé à 100 %.
Je ne suis pas un dingue de reiserfs, mais j'avoue qu'il me semble globalement plus rapide qu'ext3. Mais pas pour les compilations.
Je croyais ça aussi. Mais c'était il y a quelques mois. Maintenant je ne suis pas convaincu que ce soit encore vrai.
Puis, comme je dis, il ne faut pas confondre l'architecture kdrive et le mini serveur x11 kdrive (ou tinyX ? pour faire les testes) et dont je ne trouve plus la page web.
Conclusion (pour moi) :
Hors de question de passer à reiserfs v4 sans fsck !
Hors de question de passer à reiserfs v4 s'il est moins fiable que ext3 sur le papier (mode data=ordered).
Attendre au moins 6 mois après l'intégration dans Linux pour mes donnés "importantes" (en gros tout sauf /tmp :-)) pour qu'il soit aussi fiable dans la pratique qu'ext3.
J'ai le temps...
Une chose est sûre, Reiserfs va encore faire du bruit. J'espère que ça ne va pas me saoûler comme pour la version 3... Si on écoute les zealot, ext3 n'existerait déjà plus.
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par itstimetogo . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 2.
J'ignorais. Mais je ne suis pas le seul :
http://grammarian.homelinux.net/~mpyne/weblog/kde/gstreamer-huh.htm(...)
I wasn't even aware that aRts could do this until I saw this point become mentioned
Ça fait depuis bien longtemps qu'on est dans le registre "j'avance et tu recule, je tourne à droite et je regarde à gauche..." avec gstreamer et KDE.
Maintenant ça devient pénible.
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par itstimetogo . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 3.
Une grosse différence entre MAS et ARTS est que MAS marche aussi via réseau et il faut considérer que tu ne peux pas modifier la partie serveur (comme pour X11).
Le serveur ARTS, est pour _un_ utilisateur (celui qui vient de se logguer). A l'instar de X11, le serveur MAS est pour toutes les applis clientes qui se connectent au serveur. Le serveur MAS n'est pas lancé lorsque tu te logguent mais à l'initialisation d'X11 (ce n'est pas encore fait mais au final c'est comme ça que le serveur sera lancé).
Oui il y aura des codecs et quelques effets rudimentaires dans MAS.
Pourquoi des codecs ?
Car il faut envoyer et recevoir le son via réseau et donc compresser le son est une bonne idée. Actuellement, il n'y a que le codec mp3 dans MAS ! Et ce codec ne permet pas de coder en mp3 mais uniquement de lire.
Il y aura aussi AC5.1, ...
Il y aura un mixer évolué (c'est sur le serveur qu'il y a la carte son...).
Il y aura sûrement des features qui ne sont pas liées à un serveur de son.
X11 offre aussi des facilités et il y a eu beaucoup d'applis faitent uniquement avec libX11. Ça n'en fait pas un framework pour faire des applis graphiques.
Ce n'est pas parce que X11 affiche mon DVD que c'est un framework multimedia.
> pour Kde
Tout est là...
1 - Gstreamer utilise glib.
2 - Gstreamer à l'origine cible Gnome.
3 - Dans Gstreamer il y a 'G'.
Trois "bonnes" raisons pour KDE de ne pas utiliser Gstreamer.
Mais pour la lecture de video ça va être rigolo. Gstreamer récupère le flux video et audio (forcément), mais KDE va demander à Gstreamer de ne pas envoyer le flux audio à MAS (ce que peut faire Gstreamer). KDE va récuper le flux audio pour l'envoyer à MAS.
Un peu bordélique.
Ou KDE vire Gstreamer et utilise Xine qui utilisera MAS (bref comme Gstreamer le fait).
Quoiqu'il en soit, pour la video MAS ne sera utilisé que comme un serveur son.
> TU AVAIS TORD
KDE ne pense pas la même chose que Gnome (ou plus spécifiquement Gstreamer) qui considère MAS comme un serveur de son.
KDE ne voit pas MAS et Gstreamer de la même façon que freedesktop :
* GStreamer is a streaming media framework.
* Media Application Server™ (MAS®) is a network transparent streaming media server.
Je ne veux pas me battre avec toi (utilisateur kde?) :
KDE a raison, les autres tords (dont moi) et ils ne font que troller.
Il y a quelques temps, KDE se plaignait de la lenteur de Gstreamer à intégrer leur patch.
Je dis : que KDE n'utilise pas Gstreamer alors. Comme ça on aura la paix.
[^] # Re: Conseils ?
Posté par itstimetogo . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 2.
rc.local est vide à l'origine.
Oops, c'est faux, il y "touch /var/lock/subsys/local" :-)
Il y aura peut-être un .rpmnew pour rc.local mais tu peux l'ignorer (sûrement une mise à jour du commentaire dans le fichier). À moins que "touch /var/lock/subsys/local" soit buggé ou présente un trou de sécurité :-)
Et tu peux toujours faire un script dans /etc/rc.d/init.d/ (ala Debian).
Tu trouveras toujours un cas où il faut modifier rc.sysinit. Mais franchement, regardes les forums d'aide ou les mailings et tu verras qu'on ne propose pratiquement jamais de modifier rc.sysinit.
Et si c'était le cas, Red Hat utiliserait un système type Debian.
Ils ne sont pas cons :-)
[^] # Re: Conseils ?
Posté par itstimetogo . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 2.
J'image bien que ce n'est pas fait au hazard...
Mais la compréhension est moins "fulgurante" qu'avec un "bête" rc.sysinit.
Ceci dit, je m'en fous :-)
rc.sysinit (tel qu'il est fait par Red Hat) ou /etc/rcS.d/ ne change rien ou presque.
Par contre, j'apprécie d'avoir /etc/httpd/conf.d/ ou /etc/ld.so.conf.d/ etc.
Ça évite d'éditer /etc/httpd/conf/httpd.conf etc. Mais /etc/rc.d/rc.sysinit n'est _jamais_ édité (par les scripts d'installation de rpm par exemple).
[^] # Re: Conseils ?
Posté par itstimetogo . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 2.
J'essaie, mais je n'y arrive pas, d'expliquer pourquoi Red Hat fait comme ça.
Pour un usage classique (je ne parle pas d'embarqué qui de toute manière a des scripts spécifiques, ou de la secrétaire qui boot son PC i486 à 33Mhz 10 fois par jours).
> Si, la clarté
Pour un script de 860 lignes dont le niveau maxi d'indentation est de 5 !
Fichtre.
> un autre avec 80 fonctions de 10 lignes dans 30 fichiers, lequel est le plus clair ? :)
C'est vraiment pas évident.
Le "Red Hat touch" :
fichier init :
# init usb
(...)
# init ide
(...)
Le "Debian touch" :
fichier init :
call init_usb
call init_ide
(...)
fichier init_usb :
(...)
fichier init_ide :
(...)
Avec le "Red Hat touch", c'est évident. Tout est excécuté dans un ordre, une fois et c'est tout.
Avec le "Debian touch", si je regarde le fichier init_usb, je ne sais pas s'il doit être appelé avant ou après init_ide, je ne sais pas s'il peut être appelé plusieurs fois, etc...
Si un programme n'est pas modulaire (comme le rc.sysinit de RedHat) il est inutile de faire croire qu'il est (surtout pour 800 lignes).
[^] # Re: Conseils ?
Posté par itstimetogo . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 3.
C'est une bonne question.
Déjà, XFS est moins fiable. Je ne dis pas qu'il est codé avec les pieds mais il n'a pas le mode data=ordered d'ext3.
Voir aussi :
http://www.redhat.com/archives/fedora-test-list/2004-July/msg00034.(...)
The ext3 have almost a perfect record with the write cache off: I have run over 300 cycles on the two drives and only had two corrupted lines in the output files. So out of 600 total cycles on the two drives there were only two lines with bad data, I think that is a pretty good record.
None of the other journaling file systems have come anywhere near this performance. After 3 or 4 power cycles, ReiserFS became corrupted to the point that the system would not boot up (the fsck failed and the bootup stopped there). XFS never got corrupted to the point it wouldn't boot, but with approximately 100 power cycles on each drive, one drive had 73 corrupted lines and the other had 82. With JFS after 15 power cycles one of the drives was corrupted and the system would no longer boot up (fsck failed again).
Enfin, et ce point est important bien que souvent ignoré, Red Hat a des compétences en ext3.
S'il y a des problèmes avec xfs, RedHat n'a pas forcément les compétences en interne pour corriger ou expertiser rapidement le problème.
Si tu veux du reiserfs, prend du SuSE, ils ont les compétence. Pour ext3, regardes du côté de Red Hat. Pour XFS, install Irix :-)
Un distributeur ne peut pas avoir des compétences sur tous les FS. Surtout qu'avec toutes les combinaisons (FS/lvm/raid/acl/nfs/GFS) ça devient très très vite l'enfer pour tout tester si tu supports tous les FS (ext3, xfs, jfs, reiser3, reiser4, etc).
> mon fs favoris, c'est XFS ;)
Le mien, ext3. Principalement car il est fiable, il me suffit, il est en standard avec ma distrib (Je n'ai pas à récupérer de patch, etc) et j'ai pas envie de me prendre la tête pour gagne 0,2 % en perfo ou place disque.
Je suis fainéant et j'ai jamais pris le temps de tester les différents FS dispos sous Linux.
[^] # Re: Conseils ?
Posté par itstimetogo . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 2.
Gros ou petit fichier, ce n'est pas le point ici.
Red Hat veux que tout soit initialisé au niveau hard.
Red Hat ne veux pas qu'une partie seulement ou quelques parties au chois de l'utilisateur soient initialisées.
Tu peux critiquer cette politique si tu veux.
Si redhat fait :
include boot.usb
include boot.udev
etc
et que les fichiers sont toujours inclus (cas c'est la volonté de RedHat), ça ne change rien par rapport à un "gros" fichier.
Par contre, pour les services, Red Hat veut laisser plus de souplesse et là il y a plusieurs fichiers.
Mais faire plusieurs fichiers au-lieu d'un gros, sans un réelle objectif de modularité, n'a aucun intérêt. C'est le cas pour le rc.sysinit de RedHat :-) et donc c'est fort logiciquement qu'il n'y a qu'un seul fichier.
[^] # Re: Conseils ?
Posté par itstimetogo . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 1.
Là tu n'y es pas :-)
Désolé.
La seul optimisation que tu peux trouver à éditer rc.sysinit est en vitesse de boot. Rien d'autre. rc.sysinit ne lance pas de processus résidents etc (sauf cas exceptionnel).
De plus, s'il est possible de déplacer une partie de rc.sysinit dans /etc/init.d sans perte de fonctionnalité, ça sera fait. Mais, par exemple, déplacer l'init de usb dans /etc/init.d est une mauvaise idée (comment faire un fsck par exemple). Idem pour raid.
Afin, RedHat/Fedora est une distribution qui "just works" (enfin, ils essaient :-)).
Donc rc.sysinit doit toujours initialiser tout les périphériques de façon minimum (usb, raid, etc). Sinon ça veut dire que lorsque tu ajoutes une partition (récupérée d'une autre machine), la partition ne sera pas vue s'il n'y a pas le paquet (ou autre) sysinit_usb ou firewire ou...
Juste par curiosité, pourquoi tu veux éditer /etc/rc.d/rc.sysinit à part pour avoir un boot très très légèrement plus rapide.
[^] # Re: Conseils ?
Posté par itstimetogo . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 2.
Pour reiserfs, il y a de grosses différences entre RedHat et Mandrake :
- RedHat/Fedora ne propose pas de façon claire reiserfs. Il faut savoir qu'il faut taper "linux reiserfs" à l'invite de l'installation sinon reiserfs n'est pas proposé (idem pour jfs, xfs, etc).
- reiserfs n'est pas supporté par RHEL. Si t'es emmerdé par reiserfs, inutile d'appeler le support RH.
- RedHat (moins pour Fedora) ne fait pas l'effort de patché leur noyau avec les derniers bugfix de reiserfs. Il y a que ext3 qui est "soigné".
T'es un injuste sur ce coup avec Mandrake.
[^] # Re: Conseils ?
Posté par itstimetogo . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 3.
Juste pour information, le "monolitique" rc.sysinit fait 861 lignes sur FC2...
Y en a qui préfère 10 x 86 lignes mais c'est une affaire de gout.
Ça n'empêche pas d'avoir plein de fichiers dans /etc/rc.d/init.d/.
Sur FC2 avec tous les paquets, il y a 121 fichiers dans /etc/rc.d/init.d/ !
Enfin, rien ne t'empêche d'ajouter des tas d'include dans /etc/rc.d/rc.local .
> ce script qui ressemble au premier programme C d'un edudiant d'IUT premiere année.
Tu devrais plonger ton nez dedans avant d'avancer ça.
[^] # Re: Conseils ?
Posté par itstimetogo . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 4.
Ouais. Mais c'est rare les gens qui sont limités par la valeur par défaut lors du formatage.
En gros, une partition de 20 Go donne 2 500 000 inode !
J'ai jamais vu sur un forum quelqu'un demander à augmenter le nombre d'inode d'une partion ext3...
> quand tu dois travailler dans un environnement avec des arborescences profondes et un grand nombre de fichiers.
man tune2fs :
dir_index
Use hashed b-trees to speed up lookups in large
directories.
sparse_super
Limit the number of backup superblocks to save space
on large filesystems.
sparse_super évite d'avoir 40 superblocks à mettre à jour. La profondeur ne change rien puisque le répertoire est repéré par l'inode.
man e2fsck :
-D
Optimize directories in filesystem. This option causes e2fsck
to try to optimize all directories, either by reindexing them if
the filesystem supports directory indexing, or by sorting and
compressing directories for smaller directories, or for filesys-
tems using traditional linear directories.
> Je trouve également pesant de perdre aux alentours de 10% de ma partition pour le journal.
Où tu as vu ça ?
Exemple avec une partition de 120 Go :
# cat /proc/partitions
major minor #blocks name
9 0 120372992 md0
# df /dev/md0
Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
/dev/md0 120111456 70477292 49634164 59% /
# bc
(120372992-120111456)/120372992*100
.21727132
261536 blocks de 1k pour le FS uniquement.
Un peu plus de 0,2 % de blocs de 1K utilisé pour la gestion d'ext3. Imaginons qu'au pire de l'utilisation je monte à 0,5 % (faut beaucoup d'imagination...).
man mke2fs :
size=journal-size
Create an internal journal (i.e., stored inside the
filesystem) of size journal-size megabytes. The
size of the journal must be at least 1024 filesystem
blocks (i.e., 1MB if using 1k blocks, 4MB if using
4k blocks, etc.) and may be no more than 102,400
filesystem blocks.
On est très très loin de tes 10 %.
Tu ne confond pas avec les "Reserved blocks" qui est configurable avec "tune2fs|mke2fs -m" ? Pour les "Reserved blocks", c'est 10 % par défaut.
Utilises "tune2fs|mke2fs -m 0 /dev/partition".
[^] # Re: Innovations...
Posté par itstimetogo . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 1.
ext2 n'a pas été fait dans l'urgence. Avant il y avait ext et encore avant minix.
Tiens, j'y pense. Pourquoi les gens pour critiquer ext3 de fs pas moderne font référence à ext2 alors qu'il pourrait faire référence à ext qui est encore plus vieu :-)
[^] # Re: Récupération d'un fichier supprimé
Posté par itstimetogo . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 10.
Astuce :
Comme récupérer un fichier qui n'a plus de lien mais est encore ouvert par un processus ?
Simple, exemple :
$ cd /proc/359/fd
$ ll 6
lr-x------ 1 me me 64 aoû 25 16:22 6 -> /tmp/fichier (deleted)
$ cp 6 /tmp/fichier
Et voilà.
[^] # Re: Récupération d'un fichier supprimé
Posté par itstimetogo . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 7.
Un petit exemple pour clarifier :
[me@here tmp]$ ll -h -i
total 2,6G
16134 -rw-r--r-- 1 me me 2,6G aoû 25 07:59 gros_fichier
[me@here tmp]$ df .
Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
/dev/md0 120111456 71511120 48600336 60% /
[me@here tmp]$ ln gros_fichier gros_fichier_ln1
[me@here tmp]$ ln gros_fichier gros_fichier_ln2
[me@here tmp]$ ln gros_fichier gros_fichier_ln3
[me@here tmp]$ ln gros_fichier gros_fichier_ln4
[me@here tmp]$ ln gros_fichier gros_fichier_ln5
[me@here tmp]$ ll -h -i
total 16G
16134 -rw-r--r-- 6 me me 2,6G aoû 25 07:59 gros_fichier
16134 -rw-r--r-- 6 me me 2,6G aoû 25 07:59 gros_fichier_ln1
16134 -rw-r--r-- 6 me me 2,6G aoû 25 07:59 gros_fichier_ln2
16134 -rw-r--r-- 6 me me 2,6G aoû 25 07:59 gros_fichier_ln3
16134 -rw-r--r-- 6 me me 2,6G aoû 25 07:59 gros_fichier_ln4
16134 -rw-r--r-- 6 me me 2,6G aoû 25 07:59 gros_fichier_ln5
[me@here tmp]$ df .
Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
/dev/md0 120111456 71511120 48600336 60% /
Aucun espace disque de consommée en plus.
C'est toujours le même fichier (l'inode 16134) et le nombre de lien physique du inode/fichier est passé de 1 à 6. Le inode/fichier est supprimé lorsque le nombre de lien physique passe à 0.
D'ailleur il n'y a pas de commande (appel système) pour supprimer un fichier sous Unix !
Il y a unlink() qui supprime un lien physique. Si le nombre de lien physique passe à zero, le fichier est "enfin" supprimé.
[^] # Re: Récupération d'un fichier supprimé
Posté par itstimetogo . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 3.
DESCRIPTION Sous Unix, il existe deux types de ‘liens’ entre fichiers, que l’on nomme généralement liens matériels (ou physiques) et liens symboliques (ou logiques). Un lien matériel est simplement une manière de nommer un fichier. Un fichier peut avoir plusieurs noms. Un fichier n’est effacé réellement que lorsque son dernier nom est supprimé. Le nombre de noms d’un fichier est indiqué par la commande ls(1). Il n’y a pas de notion de nom ‘original’ : tous les noms d’un fichier ont exactement la même importance. Tous les noms d’un fichier se trouvent généralement - mais ce n’est pas obligatoire - dans le système de fichiers contenant les données du fichier. Un lien symbolique est d’un tout autre genre. Il s’agit d’un petit fichier spécial, qui contient un chemin d’accès. Ainsi un lien symbol- ique peut pointer vers un système de fichier différent de celui qui l’accueille. Il peut également pointer, grâce à NFS, vers un système de fichiers appartenant à une autre machine. Enfin, un lien symbolique ne pointe pas nécessairement vers un fichier existant.[^] # Re: jamais tu dis "bonjour" ?
Posté par itstimetogo . En réponse au message cluster linux redhat. Évalué à 3.
http://sources.redhat.com/cluster/(...)
[^] # Re: Récupération d'un fichier supprimé
Posté par itstimetogo . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 2.
Avec le bouton reset, le cpu est figé de suite (idem pour les périphériques pci, etc) et il n'y a pas vidage du cache.
Par contre le cache des disques (au niveau des disques et pas de l'OS) est écrit.
Mais c'est aussi comme ça en cas de coupure de courrant. Les disques ont un minimum d'autonomie pour assurer l'écriture (sauf les très mauvais disque).
[^] # Re: Récupération d'un fichier supprimé
Posté par itstimetogo . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 2.
Ou le bouton reset. Ça m'a déjà sauvé quelques heures de boulot.
[^] # Re: Conseils ?
Posté par itstimetogo . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 7.
Tu as raison.
Et quand on lance fsck.reiser4 on a :
*******************************************************************
This is an EXPERIMENTAL version of fsck.reiser4. Read README first.
*******************************************************************
Et dans le README :
FSCK.REISER4 WARNING
This is an experimental software yet, MAKE A BACKUP BEFORE USING IT! Do not
run rebuild unless something is broken. If you have bad sectors on a drive
it is usually a bad idea to continue using it. Then you probably should get
a working hard drive, copy the file system from the bad drive to the good
one -- dd_rescue is a good tool for that -- and only then run this program.
Ça fait penser au début de reiserfs V3 où la meilleur méthode pour corriger un fs corrompu a longtemps été mkreiserfs...
Un fs sans fsck correcte ne mérite pas d'être numéroté 1.0.0.
[^] # Re: Conseils ?
Posté par itstimetogo . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 10.
???
On peut dire qu'Unix n'a rien d'un OS moderne si on commence avec ce type d'argument.
ext3 a toutes les fonctionnalités ou presque.
lvm => ça marche
acl => ça marche
selinux => ça marche
cluster type gfs => ça marche
fiabilité => excellente
Il lui manque ces petits trucs (mais techniquement difficile à réaliser) qui permet de gagner 2 à 3 % en perfo en usage typique et à fiabilité équivalente. Le problème des benchs est qu'ils sont rarement fait à niveau de fiabilité équivalent. Ils sont concentrés sur les performances.
> Je trouve juste dommage que redhat/mdk restent bloqués sur ce fs juste pour une histoire de compatibilité ext2.
Red Hat a largement démontré qu'ils n'hésite pas à ignorer la compatibilité si ça va dans le bon sens.
Red Hat est dédié serveur et leurs utilisateurs sont plus proches des administrateurs que des hobbystes.
La compatibilité c'est bien, mais s'il faut casser la compatibilité pour avoir meilleur, il le feront.
> redhat aime bien ext3 pour des raison techniques mais qui ne concerne que la journalisation.
Pas que ça. RedHat a aussi une floppée de tests (fiabilité, tenue en charge, fonctionnalité, etc) et ext3 les passes tous ce qui n'est pas le cas de reiserfs. Parole d'Alan Cox. NB : vrai pour Linux 2.4, j'ai pas d'info pour Linux 2.6.
Si Reiserfs4 est techniquement excellent (et aussi dans la pratique :-)), complet (un fsck qui roxor aussi), performant, fiable, etc, ajoutes 6/12 mois pour que le tout soit rock solide et Red Hat utilisera reiserfs.
Puis il faut arrêter de pointer Red Hat comme un méchant qui ne veut pas utiliser reiserfs. ext3 est aussi le fs le plus utilisé par les développeurs Linux.
En gros, Red Hat fait comme la majorité des développeurs.
J'ai lu beaucoup de bien de reiserfs v4. Si c'est pas du pipo publicitaire (comme reiserfs v3), ou pour draguer les filles en discothèque, reiserfs v4 passera devant ext3 (toutes distributions confondues).
Que je sache, Linux est un logiciel libre et ce sont les meilleurs solutions qui s'imposent. Les préférences de Red Hat ne change rien à ça (au moins à long terme).
SVP : arrêtez avec le complot RedHat/mdk (Pourquoi tu parles de mdk?) pour empêcher l'"envol" de reiserfs.
[^] # Re: Conseils ?
Posté par itstimetogo . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 10.
On y voit rien !
Ext3FS :
1) Taille maximale du système de fichiers : 4 To
2) Taille de blocs : De 1 à 4 Ko
3) Taille maximale de fichier : 2 Go
1) => faux. je n'ai pas d'url sous la main mais c'est faux au moins pour Linux 2.6
2) => vrai ! bravo !
3) => faux.
Voilà un de mes répertoires (j'enregistre les JO :-) :
$ ll -h
total 14G
-rw-r--r-- 1 me me 1,5G aoû 24 21:00 JO_2004-08-24-19:52.avi
-rw-r--r-- 1 me me 2,5G aoû 24 23:00 JO_2004-08-24-21:00.avi
-rw-r--r-- 1 me me 1,8G aoû 25 00:00 JO_2004-08-24-23:00.avi
-rw-r--r-- 1 me me 4,6G aoû 25 02:00 JO_2004-08-25-00:00.avi
-rw-r--r-- 1 me me 3,8G aoû 25 03:29 JO_2004-08-25-02:00.avi
C'est qu'un exemple...
Sinon ext3 supporte aussi htree. Il faut faire :
tune2fs -O dir_index /dev/...
e2fsck -f -D /dev/...
Je veux bien admettre qu'ext3 n'est pas la F1 des FS, mais ce n'est pas une 2CV.
De plus il a presque toutes les fonctionnalités et en rock solide. Il ne manque que le resize à chaud et c'est actuellement en phase de debug (dans FC2 et ça marche :-)).
[^] # Re: Conseils ?
Posté par itstimetogo . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 5.
Pour les compilations ?
Tu es sûre ?
Quand je compile, tout est en cache et le cpu est utilisé à 100 %.
Je ne suis pas un dingue de reiserfs, mais j'avoue qu'il me semble globalement plus rapide qu'ext3. Mais pas pour les compilations.
[^] # Re: ouah
Posté par itstimetogo . En réponse à la dépêche The aKademy 2004 a commencé. Évalué à 3.
Puis, comme je dis, il ne faut pas confondre l'architecture kdrive et le mini serveur x11 kdrive (ou tinyX ? pour faire les testes) et dont je ne trouve plus la page web.
[^] # Re: Conseils ?
Posté par itstimetogo . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 10.
- ext3 à tous les étage en mode ordered (que ne fait pas reiserfs il me semble).
Pour un usage desktop, reiserfs ou ext3, ça ne change rien. C'est le cache qui compte.
=> ajoute de la mémoire :-)
> - la partition qui contient mes rushes videos DV (entre 150 et 400Mo le fichier)
Là, c'est simple encore, utilises un bon disque.
=> Change de disque :-)
Ici j'ai une grosse partition root en raid 0 stripé sur deux disques dure IDE.
Le FS : ext3
Débit écriture brute : 80 Mo/s
Débit écriture ext3 : 70 Mo/s
Débit lecture brute : 100 Mo/s
Débit lecture ext3 : 80 Mo/s
Bref, les disques comptent plus que le FS.
Sinon, il me semble que reiserfs v4 n'a toujours pas de fsck (c'est très génant).
Pour info :
Pourquoi ext3 roxor en fiabilité selon Fedora/RH (si write cache disabled pour les DD) :
http://www.redhat.com/archives/fedora-test-list/2004-July/msg00034.(...)
Le début de ce long thread :
http://www.redhat.com/archives/fedora-test-list/2004-April/msg02646(...)
Les modes ext3 :
http://www.redhat.com/archives/fedora-test-list/2004-July/msg00036.(...)
NB : ça ne parle pas de reiserfs V4.
Conclusion (pour moi) :
Hors de question de passer à reiserfs v4 sans fsck !
Hors de question de passer à reiserfs v4 s'il est moins fiable que ext3 sur le papier (mode data=ordered).
Attendre au moins 6 mois après l'intégration dans Linux pour mes donnés "importantes" (en gros tout sauf /tmp :-)) pour qu'il soit aussi fiable dans la pratique qu'ext3.
J'ai le temps...
Une chose est sûre, Reiserfs va encore faire du bruit. J'espère que ça ne va pas me saoûler comme pour la version 3... Si on écoute les zealot, ext3 n'existerait déjà plus.
[^] # Re: ouah
Posté par itstimetogo . En réponse à la dépêche The aKademy 2004 a commencé. Évalué à 2.
J'y connais rien ou presque en saissie de langue compliqué et je n'ai pas le temps ni envie de fouiller.
Tu m'as cloué le bec :-)
Balle au centre.