Reiserfs est un système de fichiers journalisé, c'est à dire qu'il apporte un gain de sécurité en terme d'intégrité des données par rapport à un système de fichiers classique. Cette version a été écrite sans utiliser le code de la version précédente, qui sera toujours maintenu pour corriger les bugs le cas échéant. Les développeurs affirment avoir conçu cette nouvelle mouture en portant une attention particulière à la qualité du code.
Reiserfs supporte les transactions atomiques : une modification sur le disque est effectuée ou non, mais elle n'est jamais effectuée "à moitié". Cela permet de s'assurer en permanence de l'intégrité du système de fichiers. Cette atomicité ne s'effectue pas au dépend des performances grâce à un algorithme assez sophistiqué.
Au menu également les "dancing trees", qui rendent obsolètes les "B-trees" utilisés auparavant. Cette technologie permet de gérer des systèmes de fichiers d'une taille importante. Reiserfs 4 intègre maintenant un système de plugins afin de faciliter le développement de fonctionnalités supplémentaires. Toutes ces fonctionnalités permettent d'envisager de nouvelles applications, ainsi sa très grande facilité de gestion de nombreux petits fichiers lui permettrait de remplacer avantageusement une base de données dans certains cas.
Au final Reiserfs met la barre assez haut et n'a pas à rougir face à ses principaux rivaux (ext3 notamment).
NdM : merci à Dario Spagnolo et à Mark Havel pour avoir également proposé des dépêches sur le sujet. NdM : Reiseir4 est distribué sous forme d'un patch pour les noyaux 2.6 récents. Ce patch a été aussi récemment intégré au patchset -ck de Con Kolivas et à la branche expérimentale -mm d'Andrew Morton. Son intégration dans le 2.6 stable n'est pour l'instant pas planifiée. Enfin, il n'est pas disponible pour les noyaux 2.4.
Aller plus loin
- Reiserfs V4 (20 clics)
- Benchmarks Reiserfs VS ext3 (10 clics)
- "dancing trees" (7 clics)
- La news sur Slashdot (3 clics)
- La news sur OSnews (2 clics)
- Téléchargement (6 clics)
# déjà qlqs commentaires là
Posté par tgl . Évalué à 6.
http://linuxfr.org/~98111/15041.html(...)
[^] # Re: déjà qlqs commentaires là ==> Performances
Posté par udok . Évalué à 8.
donc si quelqu'un connait de bons benchs récents, complets et indépendants, ça serait mieux
[^] # Re: déjà qlqs commentaires là
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
- Hans Reiser est le nom de l'auteur, un homme aussi sympathique et discret que compétent dans ce domaine. Nous l'avons rencontré lors des premières RMLL en 2000 (*).
- reiserfs nom du système de fichier créé par Hans Reiser. Il y a eu trois versions majeures.
- reiser4 C'est le nouveau système de fichier. C'est aussi un changement de nom puisque "fs" a disparu du nom et est remplacé par un chiffre.
(*) Hans Reiser et David Axmark (MySQL) ne s'étaient pas quitté pendant les RMLL. Ils avaient pu comparer la problématique des transactions avec celle de la journalisation et aborder divers autres points à la frontière de leurs spécialités. David Axmark a ensuite implémenté les transactions et reiser4 a bien des points communs avec une base de données....
# Kadreg est mailleur avec Photoshop
Posté par Pierre Tramo (site web personnel) . Évalué à 0.
Quand je vois des horreurs comme http://namesys.com/r4pics/sequencebytes.jpg(...) j'hésite à utiliser ReiserFS, craignant de retrouver mes images toutes salies avec du texte mélangé.
# Gestion des ACLs
Posté par malin nicolas . Évalué à 2.
Est ce que ReiserFS support les ACLs ?
[^] # Re: Gestion des ACLs
Posté par Anthony F. . Évalué à 1.
http://www.linuxfrench.net/gnu_linux/comment_fonctionnent_les_acl_p(...)
[^] # Re: Gestion des ACLs
Posté par Sebastien Binet . Évalué à 3.
http://thebsh.namesys.com/snapshots/2004.02.25/READ.ME(...)
Il semblerait donc bien que le support ACL soit là.
[^] # Re: Gestion des ACLs
Posté par Julien MOROT (site web personnel) . Évalué à 3.
Pour ce qui est de reiserfs 4, je ne sais pas.
[^] # Re: Gestion des ACLs
Posté par un_brice (site web personnel) . Évalué à 8.
Une bonne ocaz' de découvrir l'API donc -_^. De toutes manières, elles seront probablement implémentées de 60 manières différentes avant même que Reiserfs4 ne soit disponible en production.
[^] # Re: Gestion des ACLs
Posté par Temsa (site web personnel) . Évalué à 10.
http://okki666.free.fr/docmaster/articles/linux100.htm(...)
[^] # Re: Gestion des ACLs
Posté par tgl . Évalué à 5.
http://www.linuxfrench.net/gnu_linux/comment_fonctionnent_les_acl_p(...)
[^] # Re: Gestion des ACLs
Posté par Jean Parpaillon (site web personnel) . Évalué à -8.
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: Gestion des ACLs
Posté par Sebastien Binet . Évalué à 4.
Et bien il dit qu'il a plus de genou.
Il a peut-etre juste envie de savoir ce que c'est. Faut etre un peu ouvert dans la vie. La curiosite n'est pas un vilain defaut :)
[^] # Re: Gestion des ACLs
Posté par Jean Parpaillon (site web personnel) . Évalué à -3.
Si c'est juste pour le fun, bien sûr, il faut le faire puisque c'est inutile ;) Par contre, si c'est pour utiliser en production, vaut bien connaître le sujet.
C'est un peu comme se faire un cluster de User-Mode Linux ou installer Hurd...
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: Gestion des ACLs
Posté par Nÿco (site web personnel) . Évalué à 10.
En d'autre termes, c'est absolument nécessaire, et à vrai dire ça ne devrait pas être une option du tout, mais bel et bien une fonctionnalité de base de tout FS sous Linux. De même, toutes les applis et interfaces graphiques devraient pourvoir gérer les ACLs, ce qui est loin d'être le cas actuellement.
Un des problèmes, c'est qu'entre XFS et Ext2/Ext3, ça n'est pas la même chose (commandes, etc.). Autre problème, le mapping Samba des ACLs Linux est simple voire simpliste mais ne correspond pas (est une sous-ensemble) des ACLs du monde Windows (NT-family). Encore un autre problème, les ACLs ne sont pas sauvegardés par les outils standards (GNU tar, etc.).
Je suis partisan du "ACL-everywhere" normalisé dans le monde Linux, et ne suis pas le seul.
[^] # Re: Gestion des ACLs
Posté par DiZ . Évalué à 0.
Elles ne sont necessaires à mon avis que dans le cas d'un serveur (notament serveur de fichier).
[^] # Re: Gestion des ACLs
Posté par Nÿco (site web personnel) . Évalué à 2.
Les ACLs sont - au contraire - bien plus simples à gérer et comprendre car elles sont intuitives, ce qui n'est pas le cas du modèle rwx doublé des setuid+setgid (moins les aspects habitude de l'utilisateur/admin).
> Elles ne sont necessaires à mon avis que dans le cas d'un serveur (notament serveur de fichier).
Elles sont également nécessaires dans un environnement bureautique Samba (authentification sur domaine + partages de répertoires et d'imprimantes autant sur des serveurs que des stations), autrement dit dans le cas d'un parc bureautique hétérogène Linux+Windows, donc à peu près partout où Linux essaie de s'insérer dans une entreprise ou une administration (puisque Windows est présent partout).
Idem pour les environnements Novell a priori je pense, à vérifier. Des utilisateurs de réseaux Novell peuvent-ils nous confirmer qu'ils utilisent bien les ACLs ?
Mac OS X ayant également Samba inclus un peu partout dans le système, il doit certainement avoir des ACLs, non ? Quelqu'un pour confirmer ?
[^] # Re: Gestion des ACLs
Posté par DiZ . Évalué à 2.
>sont intuitives, ce qui n'est pas le cas du modèle rwx doublé des setuid+setgid
>(moins les aspects habitude de l'utilisateur/admin).
http://www.suse.de/~agruen/acl/linux-acls/online/(...) pour vous faire une idée et comparer avec les droits *nix classique :)
>> Elles ne sont necessaires à mon avis que dans le cas d'un serveur (notament serveur de fichier).
>Elles sont également nécessaires dans un environnement bureautique Samba
Je crois que tu répètes ce que je viens de dire....
A noter qu'il faut pas que ce soit trop homogène non plus MacOS9 n'aime pas les ACL...
[^] # Re: Gestion des ACLs
Posté par gaolinn . Évalué à 2.
[^] # Re: Gestion des ACLs
Posté par Thomas S. (site web personnel) . Évalué à 4.
> simpliste mais ne correspond pas (est une sous-ensemble) des ACLs
> du monde Windows (NT-family)
C'est pas trop le mapping samba qui pose problème, c'est plutôt le modéle des ACL posix non ? Les ACL Windows à partir de 2000 sont bien plus complettes et compliqué que les ACL posix.
Ce qui me géne le plus c'est le manque de délégation pour la gestion des droits des fichiers (seul root et le owner ont ce droit).
> Je suis partisan du "ACL-everywhere" normalisé dans le monde Linux,
> et ne suis pas le seul.
Ensemble ça fait déjà deux ;)
[^] # Re: Gestion des ACLs
Posté par Nÿco (site web personnel) . Évalué à 2.
s/bien plus/trop/ ?
Il y a vraiment trop de bruit dans les ACLs NT àmha. Mais bon, GNU/Linux sans ACLs fait quand même playschool à côté... ;-)
[^] # Re: Gestion des ACLs
Posté par Tom Sheldon . Évalué à 4.
Pour ce qui est de la délégation, SELinux devrait apporter un équivalent bien plus puissant.
Le hic pour l'instant reste la complexité de sa mise en place, mais debian, gentoo, redhat, suse sont en train d'y reflechir pour apporter ces outils à l'utilisateur de tout les jours. Ca avance, et vite !
Ce que j'attend avec impatience pour m'y lancer à fond, c'est la gestion SELinux d'Xfree.
Actuellement en cours de développement dans le cvs d'XOrg (branche XACE), sa sortie devrait démocratiser son utilisation.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Gestion des ACLs
Posté par gnumdk (site web personnel) . Évalué à 3.
Pour le 4 je sais pas.
# Conseils ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 7.
Cependant, j'entend parler de ReiserFS, XFS, etc...
J'aimerais savoir lequels employer pour un maximum de performances pour :
- la partition /
- la partition /home/
- la partition qui contient mes rushes videos DV (entre 150 et 400Mo le fichier)
Qu'ai-je à gagner à utiliser un système plutôt qu'un autre ?
Je remercie d'avance celui qui prendra la peine d'un jour faire une petite comparaison assez simple et les domaines d'utilisation spécialisés de chaque FS. Je crois que je ne serai pas le seul à en profiter ;-)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Conseils ?
Posté par Yusei (Mastodon) . Évalué à 5.
Cependant, cet avantage perd de son importance au fil du temps. Moins la mémoire sera limitée et plus les noyaux supporteront de systèmes de fichier de base.
[^] # Re: Conseils ?
Posté par Nico_206 (site web personnel) . Évalué à 8.
Je suis étonné que l'on compare reiserfs a l'ext3 qui est très lent.
Reiserfs est en théorie très rapide sur les petits fichier.
Le fs super rapide est l'ext2 mais n'est presque plus d'actualité pour les partition autres que le /boot. Attention au crash !
xfs est souvent bien classé mais j'ai eu pas mal de soucis avec lors de plantage -> fichiers corrompu. (le genre de truc que l'on évite avec les transaction atomique par ex).
Là je suis plutot content de ma reiserfs 3.6
[^] # Re: Conseils ?
Posté par ratatum . Évalué à 3.
D'aprés leurs benchs reiserfs4 semble être plus rapide que l'ext2 maintenant.
Par contre, les résultats CPU_TIME indiquent qu'il sollicite plus le processeur.
Quelqu'un sait il à quoi correspond la colonne DF?
[^] # Re: Conseils ?
Posté par Olivier Jeannet . Évalué à 7.
Je suppose qu'il s'agit du nombre de blocs occupés (ou libres), résultat de la commande usuelle "df", pour évaluer l'effacité de stockage du FS.
[^] # Re: Conseils ?
Posté par Gaétan RYCKEBOER . Évalué à 1.
Y'a plein de soucis dans des cas, genre si ton fichier journal est en vrac, si t'as certains type de corruption, etc, qui font que tu n'y arrivera pas forcément. Il vaut vraiment mieux avoir un kernel qui connaît bien ton FS, et les fsck qui vont avec.
Et le souci, c'est que tu monte toujours un vieux noyau quand ton FS est corrompu.. donc en plein dedans :)
Mais c'est vrai que la compatibilité EXT2/3, sur touts les autres aspects, est pratique.
[^] # Re: Conseils ?
Posté par tgl . Évalué à 10.
Sinon, de ce que j'ai lu, c'est probablement XFS qui serait le plus adapté à ta partoche de vidéos. Il est apparement le plus performant pour les accès bien linéaires à des gros fichiers (streaming ou capture vidéo, etc.).
Quant à Reiser4, perso je vais tester pour ma prochaine installe de distrib¹. Sur le papier au moins, la robustesse à l'air d'être au rendez-vous cette fois, mais surtout j'ai bien envie de jouer avec les plugins, les fichiers aggregés, tout ça quoi. Y'a vraiment de l'inovation sur les features et pas juste une course à la vitesse, et ça ça mérite d'être essayé.
¹ D'ailleurs si qlqun connais un LiveCD supportant Reiser4 pour que je puisse amorcer un install gentoo, ça m'intérresse. Enfin sinon j'en ferais un, c'est pas bien grave.
[^] # Re: Conseils ?
Posté par itstimetogo . É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: Conseils ?
Posté par tgl . Évalué à 3.
Comme tu le dis plus bas, ça n'est vrai que si la mémoire suit. À l'époque où j'utilisait du reiserfs, j'étais sur une petite config très juste à ce niveau, et ceci explique peut être celà. Bon maintenant, c'est vieux, donc je vais pas jurer cracher non plus, mais quand même, mon souvenir est vraiment celui d'une bonne surprise à ce niveau les premières fois que j'avais testé reiserfs.
[^] # Re: Conseils ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
[^] # Re: Conseils ?
Posté par Tom Sheldon . Évalué à 3.
Reiser et ext3 n'ont pas d'optimisations spéciales quand aux compilations. Ce qui n'est pas le cas de reiser4 puisque, dès sa sortie, il supporte déja le plugin "fibration" qui consister à "mettre" cote à cote les fichiers ayant une extention identique, ce qui tendrait à accélérer les lectures/ecritures des .o et .c lors des compilations.
[^] # Re: Conseils ?
Posté par SF . Évalué à 4.
La derniere YOPER en mode rescue semble répondre à ton besoin.
http://www.yoper.com/(...)
"Known to be a commercial strength Desktop Solution at 0 cost, this release provides the power user with many new features, encompassing REISER4 support for the root filesystem, new non-destructive NTFS resizing, graphical partitioning, option to use GRUB or LILO bootloaders, a new clustered control panel, KDE 3.3.0 Final, Linux Kernel 2.6.8.1, default Firewall and the OpenOffice.org Office Suite, all provided on 1 CD. The default "look and feel" has been enhanced and many bugfixes have been applied, including PCMCIA support during install and support for PPPoE."
[^] # Re: Conseils ?
Posté par tgl . Évalué à 2.
[^] # Re: Conseils ?
Posté par gallenza . Évalué à 8.
Pour y voir plus claire : http://jfenal.free.fr/Traduc/LG55D/lg55d-fr/lg55d-fr-4.html(...)
[^] # Re: Conseils ?
Posté par Olivier Jeannet . Évalué à 7.
ext2 n'est pas le plus récent des systèmes de fichiers, mais il reste assez performant, même sur grosses partitions (qui n'existaient pas quand le FS a été conçu). En usage courant, chez moi ext3 est tout à fait satisfaisant (par ex, un "dd if=/dev/zero of=/big/toto" sur 1 Go se déroule à une vitesse proche de la vitesse d'écriture brute du disque), en tous cas je n'ai jamais perdu de fichier (il est vrai que je n'ai que très rarement eu de coupure brutale ou plantage), et c'est le plus important à mes yeux.
Je ne suis pas sûr qu'un FS conçu plus récemment soit beaucoup plus performant, surtout pour l'usage que nous avons généralement de nos machines (en tant que particulier).
NB: c'est antédiluvien ("anté" = avant, "diluvien" indique le déluge).
[^] # Re: Conseils ?
Posté par itstimetogo . É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 gnumdk (site web personnel) . Évalué à 2.
Mwai, il n'empeche que ext3 n'a rien d'un fs moderne, il a pour base ext2 et c'est ca qui craint le plus. Il y'avait eu un tres bon article dans Linux Mag y'a deux ans(me semble) sur le sujet qui expliquait les caracteristiques de tous les FS.
Je trouve juste dommage que redhat/mdk restent bloqués sur ce fs juste pour une histoire de compatibilité ext2. Bon, je sais, comme tu l'as dit, y'a pas que ca, redhat aime bien ext3 pour des raison techniques mais qui ne concerne que la journalisation.
[^] # Re: Conseils ?
Posté par Romuald Delavergne . Évalué à 9.
Je ne vois pas pourquoi ext2 crait. Au contraire c'est sans doute le système de fichier le plus robuste et le plus éprouvé. Regarde les changelogs et tu comprendras. Et je trouve bien qu'on se base sur un système de fichiers robuste afin d'hériter de la caractéristique primordiale. C'est vrai qu'Ext3 a eu et a encore quelques désavantages par rapport aux autres dû à l'heritage d'ext2 (acl, taille maximum...) mais peu à peu il les comble. Et je trouve ça plutôt sain comme mode de développement.
Sur le papier reiserfs 4 est peut-être le meilleur. Maintenant faut voir en pratique parce que on a eu le même discours avec la version 3 et pour être reparti de zéro faut croire qu'il était pas si bien que ça.
[^] # Re: Conseils ?
Posté par gnumdk (site web personnel) . Évalué à 3.
Oui, mais un fs vieux avec de vieux concepts dedans, pour resumer l'article de linux mag. En clair, XFS, reiserfs et autres utilisent des algos bien plus perfectionnés que ce que l'on trouve dans ext2.
"et pour être reparti de zéro faut croire qu'il était pas si bien que ça. "
Rien à voir, c'est pas parce que ils ont innovés que l'ancienne version etait mauvaise.
[^] # Re: Conseils ?
Posté par Christophe Lucas (site web personnel) . Évalué à 8.
Et pour toi cela suffit à dire qu'un système de fichier craint ???
Pour moi, un SGF qui craint est un système de fichier peu fiable, peu performant... Dis tu que ext3 est ainsi ?
Pour ma part j'ai eu quelques coupure violentes et je n'ai jamais eu aucun problème. Je touche de la peau de singe (oups c'est ma tête).
Tu sembles dire que Redhat et Mandrake restent sur ext3 et que cela est dommage. Néanmoins, je pense que leur équipe de développement et des gens comme Alan Cox sont largement compétents pour prendre telle descision :-)
Alors là je suis totalement d'accord avec toi. Ils ont eu d'autres idées et ont essayer d'évoluer et progresse voilà tout.
Christophe
[^] # Re: Conseils ?
Posté par gnumdk (site web personnel) . Évalué à 2.
Ext3 est montrer comme un fs moderne et ce n'est pas le cas, comme le disait l'article de LinuxMag, c'est un fs de transition pour ext2. Mais sur une machine neuve, mieux vaut passer à quelques chose de mieux pensé. J'ai pas dit ext3 craint, j'ai dit ext2 craint. Je suis sur que la partie journalisation de ext3 est de bonne qualité mais le fs dessous(ext2) lui est tres basique. C'est un peu comme si Microsoft avait sortie la Fat 32++ (Fat 32 + journalisation + ACL) au lieu de NTFS ;)
"Tu sembles dire que Redhat et Mandrake restent sur ext3 et que cela est dommage. Néanmoins, je pense que leur équipe de développement et des gens comme Alan Cox sont largement compétents pour prendre telle descision :-)"
Deja, tu enleves Mandrake vu que leur politique est de faire comme RedHat :) Il y'a plein de truc suxorisant dans la Mandrake qui sont la paske c'est comme ca chez RedHat: le rc.sysinit par exemple. Je sais je me repete, mais bon, quand on compare un init Debian/Suse(similaire) à un init RedHat/Mandrake, y'a d'un coté la modularité et de l'autre la rigidité. Et franchement, je crois que leurs equipes de devel(de rh et mdk) sont capables d'ecrire un truc un peu mieux pensé que ce script qui ressemble au premier programme C d'un edudiant d'IUT premiere année.
Donc dire RedHat l'a choisit donc c'est une bonne solution, ca me fait sourire ;)
[^] # Re: Conseils ?
Posté par gnujsa . Évalué à 5.
Hormis l'effet dévalorisant que tu semble chercher à produire en comparant fat et ext2, j'ai l'impression, sans être un spécialiste, que fat et ntfs sont beaucoups plus éloigné l'un de l'autre que ext2 et ext3/reseirfs/xfs, ...
Déjà rien que le fait que ext2, ntfs, reseirfs sont multiutilisateur et pas fat.
gnumdk:
« [...]Il y'a plein de truc suxorisant dans la Mandrake[...] »
On renie son premier amour ? ;-)
[^] # Re: Conseils ?
Posté par gnumdk (site web personnel) . Évalué à 2.
Non, je dis ce que je pense ;)
Apres, et ce n'est que mon avis personnel, je me trompe peut etre, je pense que cette volonté de MandrakeSoft de rester proche de RedHat est surement la pour s'assuré une meilleur compatiblité avec les solutions proprios utilisées en entreprise: Oracle, ... et certifié RedHat. En effet, si Mandrake prend le large par rapport a RedHat, il risque d'etre plus difficile de faire fonctionner ce genre de soft sur une Mandrake.
Mais sur d'autre points, Mandrake a su se remettre en question: la modularité des packages par exemple qui se rapproche(sans etre aussi modulaire) de ce que l'on a chez Debian.
C'est marrant cette facon que les gens ont de croire qu'une critique n'a lieu que pour descendre ce que l'on utilise pas ;).
La distrib que j'utilise actuellement a une facon tres bizarre de packager :) On a du kdebase3, du kdelibs3 à la redhat mais on a du koffice-wordprocessor à la Debian. J'ai toujours pas compris la logique du truc mais bon :)
[^] # Re: Conseils ?
Posté par itstimetogo . É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 gnumdk (site web personnel) . Évalué à 3.
Oui, mais ca empeche de virer des choses lors de l'init autrement qu'a grand coup de vim ;)
sous Debian,
update-rc.d -f bootmisc.sh remove
sous RH/Mandrake
vim /etc/rc.sysinit à la recherche du truc.
"Tu devrais plonger ton nez dedans avant d'avancer ça."
Vu qu'il est tres similaire à celui de la Mandrake et que je connais celui de la Mandrake(on va dire juska la 9.2) tres bien. Je pense pas avoir besoin de le faire.
Il faut voir que ce script fait tout et n'importe quoi: hdparm, hostname, ...
Sous une Suse par exemple, la modularité est tres bonne:
gnumdk@linux:/etc/init.d> ls boot.[!d]*
boot.clock boot.klog boot.md boot.scsidev
boot.crypto boot.ldconfig boot.proc boot.shm
boot.evms boot.loadmodules boot.restore_permissions boot.swap
boot.idedma boot.local boot.rootfsck boot.sysctl
boot.ipconfig boot.localfs boot.sched boot.udev
boot.isapnp boot.localnet boot.scpm
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.
[^] # Re: Conseils ?
Posté par itstimetogo . É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 . É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 gnumdk (site web personnel) . Évalué à 2.
Tu n'as pas compris, c'est pas parce que les fichier sont dans init.d que ca se lance comme les autres services. Comme sous Debian, c'est un autre fonctionnement. Et il n'y pas de perte de fonctionnalité.
Apres, le fait de pouvoir virer quelques parties permet sur de tres vieille babasse de gagner un temps precieux au boot ;) Surtout pour le pc de saisie de note de la secretaire qui trouve deja mozilla long a se lancer, alors si en plus le boot est long... :)
Mais la n'est pas mon argument principal, il s'agit d'abord d'un probleme de clarté. Suse n'offre aucun outils autre que rm pour virer les liens de boot.* dans /etc/init.d/boot.d (sous debian /etc/rcS.d).
Debian offre cette possibilité via la commande update-rc.d.
"et que les fichiers sont toujours inclus (cas c'est la volonté de RedHat), ça ne change rien par rapport à un "gros" fichier."
Si, la clarté. Si je te code un prog avec une fonction de 800 lignes dans un fichier et un autre avec 80 fonctions de 10 lignes dans 30 fichiers, lequel est le plus clair ? :)
Et ton argument : " Red Hat ne veux pas qu'une partie seulement ou quelques parties au chois de l'utilisateur soient initialisées." est vraiment moisi! Le mec qui s'interresse au boot de la redhat, c'est qu'il en a besoin et qu'il sait ce qu'il fait ;)
[^] # Re: Conseils ?
Posté par itstimetogo . É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 gnujsa . Évalué à 3.
Un petit aperçu ici:
http://www.debian.org/doc/manuals/reference/ch-system.fr.html#s-ini(...)
« 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... »
ex:
/etc/rcS.d/S26lvm -> ../init.d/lvm
/etc/rcS.d/S35mountall.sh -> ../init.d/mountall.sh
D'aprés le nom des liens symboliques : S pour Start. Le script lvm démarre en 26ième position alors que mountall.sh démarre en 35 ième position.
[^] # Re: Conseils ?
Posté par itstimetogo . É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 gnumdk (site web personnel) . Évalué à 2.
Oui, mais il peut etre mis a jour dans une update.
Et si tu le modifie pour ajouter des truc, tu te retrouves a devoir mergé la correction du bug dans ton script vu que rpm a crée un .rpmnew.
[^] # Re: Conseils ?
Posté par itstimetogo . É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 Christophe Lucas (site web personnel) . Évalué à 0.
Est-ce que ReiserFS est-il bien plus performant et plus fiable qu'Ext3 ?????????????
Si cela m'est démontré alors, j'admettrais que mon point de vue est caduque. Néanmoins, jusqu'à là c'est le choix de certains d'utiliser ext3.
De plus, la réponse à ma question ne semble pas encore bien claire...
Alors l'argument, c'est plus moderne, c'est mieux pensé, me fait franchement sourire... On dirait : "oh il me manque le dernier schmurff en vogue sur ma machine !!". Alors en effet, c'est peut-être la dernière feature à la mode, mais pour l'instant il ne semble pas que tout ce qui semble vitale aux entreprises est dans ReiserFS !
J'en conclu que ext3 ne craint pas ;-)
Ai-je dis cela ? J'ai dis que c'était _leur_ décision et qu'ils étaient compétents pour choisir si tel ou tel système de fichier correspond à leur attente.
Douterais-tu de leur compétence ? Es-tu meilleur que ces équipes de dev ? Tes arguments semblent convaincants, contactes RH (et MDK)...
Bonne journée.
Christophe
[^] # Re: Conseils ?
Posté par gnumdk (site web personnel) . Évalué à 3.
GNU/Hurd a de moins bonnes perfs que GNU/Linux, pourtant GNU/Hurd est meilleur techniquement! Donc oui, ton point de vue est caduque ;) Et si tu regarde n'importe quel bench comparant XFS, reiserfs et ext3, XFS et Reiserfs seront tjs devant(avec des nuance entre les deux suivant le bench) et ext3 derriere. Par contre, ext2 lui est plus performant que tout les autres :) Mais rajouter la journalisation à quelque chose qui n'a pas été concu pour, ca donne pas de meilleurs perfs et en principe, il vaut mieux tout recommencer. Et de toute facon, ext3 est la pour la compatibilité, et pour cela c'est tres bien qu'il soit la!
"Douterais-tu de leur compétence ? Es-tu meilleur que ces équipes de dev ? Tes arguments semblent convaincants, contactes RH (et MDK)..."
Moi meilleur? mouahahah :) non :)
Mais bon, d'apres ce que j'ai compris(meme si je n'aime pas le rc.sysinit de RedHat), c'est plus problematique chez Mandrake qui met tout est n'importe quoi dans ce script(qui a depassé les 1000 lignes depuis un moment :) Ensuite, j'ai prevenu MandrakeSoft, si tu regardes la ml cooker, tu veras deux mail de moi sur le sujet à 6 mois d'intervalle(j'aim bien insister) mais bon, si ils veulent pas, je peux pas les forcer ;)
[^] # Re: Conseils ?
Posté par tgl . Évalué à 5.
> discours avec la version 3 et pour être reparti de zéro faut
> croire qu'il était pas si bien que ça.
Mmmh... les objectifs de Reseir4 sont complètement différents, et il y a eu pour Reseir4 un paquet d'idées nouvelles, donc ça n'aurait pas eu grand sens de partir sur la base de ReseirFS 3. Mais ça ne prouve en rien que ReseirFS 3 était un échec ; qu'une boîte se lance dans un nouveau projet n'indique pas systématiquement qu'elle juge les pré précédents bons pour la poubelle.
[^] # Re: Conseils ?
Posté par itstimetogo . É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 Richard Van Den Boom . Évalué à 3.
C'est probablement la seule vraie limitation que je lui vois, mais elle va de pair avec sa relative lenteur sur de répertoires avec beaucoup de petits fichiers. Je trouve également pesant de perdre aux alentours de 10% de ma partition pour le journal.
En ce qui me concerne, je trouve Ext3 bien mais ReiserFS3 mieux, donc j'utilise Reiser. Donc j'évite Red Hat (mais ça j'aurais évité de toutes les façons).
Richard
[^] # Re: Conseils ?
Posté par itstimetogo . É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: Conseils ?
Posté par Richard Van Den Boom . Évalué à 2.
D'autre part, c'est très bien de pouvoir tuner EXT3 pour certains usages spécifiques mais j'imagine que du coup, ils sont moins efficaces sur d'autres usages. Tant qu'à faire je préfère le système de fichiers qui me fournit tous ces avantages sans inconvénients par défaut.
Pour la taille du journal, je n'avais qu'une petite partition comme référence, donc effectivement, c'est un mauvais argument.
Richard
[^] # Re: Conseils ?
Posté par 007 . Évalué à 1.
Temporaires ?!?
Il y a un problème alors.
M'enfin, en gros avec les paramètres par défaut, il y a 1 inodes pour 2 à 3 blocks.
Le maxi est 1 inodes par block (pour reiserfs ça doit aussi être le cas).
Bref, il faut vraiment en vouloir pour atteindre la limite de la valeur par défaut.
Je ne dis pas que ça n'arrive pas. Mais ça doit être rare.
Rendre la taille de la table des inodes dynamique est dans la TODO list. Ça passera peut-être par par un "umount ... ; tune2fs ... ; e2fsck (peut-être) ; mount".
Pas de délais annoncé.
[^] # Re: Conseils ?
Posté par gnumdk (site web personnel) . Évalué à 4.
Oui, c'est le cas ;) Ca m'empeche pas de l'utiliser mais je sais tres bien que Unix est loin d'etre parfait. Mais moi au moins je l'avoue :p
"SVP : arrêtez avec le complot RedHat/mdk (Pourquoi tu parles de mdk?) pour empêcher l'"envol" de reiserfs. "
Je parle de Mandrake parce que... Ben c'est expliqué deux commantaires plus haut ;) Mandrake a peur de s'eloigner de RedHat. C'est l'argument choc que l'on m'a sortie quand j'ai proposé aux devels de chez mdk de repenser leur init afin d'avoir quelque chose de plus modulaire.
[^] # Re: Conseils ?
Posté par itstimetogo . É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 gnumdk (site web personnel) . Évalué à 2.
"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."
Désolé pour ce croisement de commentaire, c'est mal :)
Mais, XFS est la depuis longtemps, stable et a fait ses preuves chez SGI. Depuis le 2.6.0, il est officiellement dans le noyau et pourtant la fedora ne l'utilise pas par defaut. Pourquoi? :)
Et vu que tu as l'air de croire que je suis un grand fan de reiserfs, c'est pas du tout le cas, mon fs favoris, c'est XFS ;)
[^] # Re: Conseils ?
Posté par itstimetogo . É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 Cook Captain . Évalué à 3.
Le cas d'Unix me semble justement un trés bon exemple. Des bonnes fondations ont permis au système de s'améliorer au fil des années et ce sans renier son passé. Certains OS supposés plus modernes que Linux/Unix ne parviennent pas forcément à le supasser dans biens de domaines. Unix n'est certes toujours pas parfait, mais à ma connaissance aucun OS ne l'est (fort heureusement!).
En ce qui concerne les systèmes de fichiers, les benchs de tests ne sont que très peu révélateurs de l'efficacité réelle du FS. La fiabilité me semble absolument primordiale. Malheureusement cette donnée n'est pratiquement jamais testée. Dans ce domaine, ReiserFS 3 avait peu convaincu (d'ou à mon avis son manque de succès), J'espère que la version 4 sera plus performante de ce coté. Rdv dans 1 an...
[^] # Re: Conseils ?
Posté par 007 . Évalué à 1.
Une fourchette est moderne.
MS-DOS n'est pas moderne.
Unix est moderne depuis 30 ans :-)
[^] # Re: Conseils ?
Posté par Mr F . Évalué à 2.
Moderne se dit d'une chose utilisé depuis peu, et se dit aussi d'une chose utilisant des concepts novateur.
Une fourchette n'est pas moderne.
La base d'Unix n'est pas moderne, mais le kernel 2.6 par exemple est moderne.
etc...
Maintenant, comme tu le dit si bien, il existe des choses que l'on ne peut qualifié de moderne (une fourchette) qui n'ont pourtant pas trouvé de meilleur remplaçant...
Comme quoi la modernité et l'efficacité sont deux concepts distincts.
[^] # Re: Conseils ?
Posté par 007 . É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: Conseils ?
Posté par Cook Captain . Évalué à 2.
utilisation moderne => utilisé depuis peu
conception moderne => conçu depuis peu
Cela signifie qu'un objet peut être de conception ancienne (donc non moderne) et d'utilisation moderne.
Le 'depuis peu' exprime une durée relative à l'espace de temps dans lequel on se situe.
La création d'Unix est donc ancienne (à l'échelle de l'infomatique). En revanche, de nouvelles techniques sont ajoutées chaque jour a linux. On pourrait donc dire que Linux est un os moderne dont les origines sont anciennes...
Bref tout cela c'est pas simple ....
[^] # Re: Conseils ?
Posté par Mr F . Évalué à 2.
C'est pareil pour l'informatique, Unix n'est absolument pas plus moderne que MS DOS. La base de Linux n'est pas moderne non plus, car au vu de l'ancienneté de l'informatique domestique, cela fait longtemps qu'il a vu le jour. Mais comme je le disais, certains concepts de Linux sont moderne.
Tu confond de notre temps (de notre époque) à "utilisé encore actuellement", ce qui est totalement différent, la fourchette est bien encore utilisé actuellement...
[^] # Re: Conseils ?
Posté par 007 . Évalué à 1.
Unix (n')est (pas) de notre temps.
Unix (n')est (pas) utilisé encore actuellement.
J'y comprend rien.
Il me semble, et j'ai peu de doute sur ça, qu'Unix est de notre temps et est encore utilisé.
Unix se trouve facilement aujourd'hui (OS, articles, etc...). Il est donc de notre temps.
Unix est utilisé.
> Unix n'est absolument pas plus moderne que MS DOS.
Impressionnant.
[^] # Re: Conseils ?
Posté par Mr F . Évalué à 2.
Enfin bref, nous n'avons pas la même perception des choses et tu essaye de raisonner avec une explication litéraire.
Mais je persiste et signe, et je pense que tu pourrais demander à ton entourage (en leur donnant des dates) pour qu'ils te disent ce qu'ils en pensent, tu es dans l'erreur.
[^] # Re: Conseils ?
Posté par 007 . Évalué à 1.
Je fais de mon mieux pour parler français et pas la banlieu.
Alors ziva, lâche moi la grappe :-)
Sinon j'ai mon "micro robert" (pas très litéraire...).
Moderne :
1- Actuel, contemporain, récent
2- Qui bénéficie des progrès récents, correspond au goût actuel
3- (personnes) qui tient compte de l'évolution récente dans son domaine
Le 1 et le 2 me conviennent. Le 3 pour les personnes me convient aussi.
Unix tombe en 1 et Linux plutôt en 2.
Tu préfères ne retenir que le 2.
Le français étant une langue vivante, je ne vais pas te le reprocher.
[^] # Re: Conseils ?
Posté par Mr F . Évalué à 2.
Ensuite, Unix et même Linux n'ont rien de contemporain, un OS contemporain serait Windows ou MacOSX ou Pegasos etc, mais surement pas Unix qui date de la décennie précédente. Et encore une fois, le fait qu'il soit utilisé et qu'il convienne parfaitement à nombre d'utilisation ne veut pas dire qu'il soit moderne.
Le français étant une langue vivante, je ne vais pas te le reprocher.
Justement, c'est pour cela qu'il ne faut pas se baser sur un sens littéraire, le Français bouge et si tu prend un dictionnaire de 1920, tu serais bien surpris de la définition qu'avaient certains mots...
Le débât est sans fin et l'on trouvera des partisants des deux cotés, mais pour moi Unix n'est pas moderne, même si c'est l'OS que je préfére et qui me correspond le mieux.
[^] # Re: Conseils ?
Posté par 007 . Évalué à 1.
Après MS-DOS plus moderne qu'Unix...
btw, Unix a implémenté Internet (ipv4, mail, ftp, uucp, etc) bien avant Windows.
Le modèle ouvert d'Unix (normes) et le modèle open-source de Linux (et pourtant l'idée est vieille...) et beaucoup plus moderne/novateur que le modèle fermé basé sur l'exclusivité et capitaliste de Windows. C'est d'ailleur tellement "moderne" que beaucoup de journalistes et politiciens ne l'ont pas encore intégré.
> Justement, c'est pour cela qu'il ne faut pas se baser sur un sens littéraire
> un dictionnaire de 1920
Pour être honnète, tu m'énerves un peu.
1- Je n'ai pas pris un dico de littérature.
2- Mon "Robert" date de 1997 (c'est vieu mais c'est correct).
3- Toi et/ou ton quartier n'est pas forcément la meilleur référence pour le Français.
Désolé.
[^] # Re: Conseils ?
Posté par Mr F . Évalué à 2.
Il y a 10 ans voir même 5 ans c'était un OS moderne :-)
Le modèle ouvert d'Unix (normes) et le modèle open-source de Linux (et pourtant l'idée est vieille...) et beaucoup plus moderne/novateur que le modèle fermé basé sur l'exclusivité et capitaliste de Windows. C'est d'ailleur tellement "moderne" que beaucoup de journalistes et politiciens ne l'ont pas encore intégré.
Oui enfin à noter quand même que le modèle n'est pas une invention de l'Open Source :-)
Pour être honnète, tu m'énerves un peu.
1- Je n'ai pas pris un dico de littérature.
2- Mon "Robert" date de 1997 (c'est vieu mais c'est correct).
3- Toi et/ou ton quartier n'est pas forcément la meilleur référence pour le Français.
ça n'émpèche en rien que qualifié Unix d'OS moderne, en 2004, est faux. Mais Unix (ou plutôt Linux) est un OS contenant des concepts modernes. C'est toute la différence :-)
Mais bref, peut importe.
[^] # Re: Conseils ?
Posté par 007 . Évalué à 1.
Oui. Mais un petit truc. Je ne pense pas que la modernité se mesure sur une ou deux années.
Internet à plus de 20 ans et c'est depuis fin 90 que ça conserne nos "contemporains".
C'est depuis 2 ans environ que beaucoup de foyer français ont Internet.
L'accès à Internet, l'utilisation d'Internet, ses conséquences, etc reste un point chaud et le moins qu'on puisse dire, c'est que ça reste globalement opaque pour le citoyen moyen et pire encore pour les politiciens/journalistes et même pour les spécialistes (qui par exemple n'ont pas vu venir Internet ni Linux et un fois sur deux disent des conneries).
Pour ma part, tout ce qui conserne l'informatique et qui est utilisé actuellement est moderne (même en insistant sur "récent").
[^] # Mur
Posté par Mr F . Évalué à 2.
Oui. Mais un petit truc. Je ne pense pas que la modernité se mesure sur une ou deux années.
C'est une question de contexte et de relativité. Sur quelque chose comme les transport qui évolue lentement, clairement pas. Sur quelque chose comme l'informatique qui évolue très vite, ta modernité d'il y a deux ans peut être complétement dépassé.
C'est depuis 2 ans environ que beaucoup de foyer français ont Internet.
L'accès à Internet, l'utilisation d'Internet, ses conséquences, etc reste un point chaud et le moins qu'on puisse dire, c'est que ça reste globalement opaque pour le citoyen moyen et pire encore pour les politiciens/journalistes et même pour les spécialistes (qui par exemple n'ont pas vu venir Internet ni Linux et un fois sur deux disent des conneries).
Aucun rapport, on juge une modernité (ou autre) sur un aspect globale de création, pas de démocratisation massive. De toute façon, dès que ça devient démocratisé, c'est moins moderne. Exemple l'Ipod, c'est moderne, mais tout le monde n'en a pas. Le téléphone portable, c'est plus vraiment moderne (ça date) et maintenant tout le monde ou presque en as.
Pour les "spécialistes", ils ont, tout au long de l'histoires, pratiquement jamais rien vu arrivé alors il ne faut pas trop s'en étonner pour le LL.
Pour ma part, tout ce qui conserne l'informatique et qui est utilisé actuellement est moderne (même en insistant sur "récent").
J'ai bien compris ton point de vue et tu reste opaque au miens et à mes arguments :
Etre utilisé actuellement ne veut pas dire être moderne. Exemple un browser n'est pas moderne, le concept est vieux. Par contre le css et le xml sont des concepts modernes. Bien qu'ils commencent à le devenir un peu moins avec le temps...
Bref, encore bref, Unix n'est pas moderne (il date d'au moins 1990) (je n'ai plus de date en tête) et 14 ans, c'est énorme en informatique. Mais, encore une fois, certains concepts de Linux sont modernes.
[^] # Re: Mur
Posté par 007 . Évalué à 1.
Selon ta définition, non.
C'est SGML en plus simple et SGML date de 15 ou 20 ans (j'ai oublié).
Pour css, la séparation de la présentation et des données est un très vieux concept aussi.
> Unix n'est pas moderne (il date d'au moins 1990)
Rires...
Unix, même époque que le language C. C-à-d fin 60 début 70.
> et 14 ans, c'est énorme en informatique
L'informatique en est encore à ses débuts. Au début de l'aviation ou de l'automobile, 14 ans c'était énorme aussi.
Tu peux aussi affirmer que l'avion n'est pas un mode de transport moderne alors.
> certains concepts de Linux sont modernes.
En fait, très peu. En tout cas pour l'utilisateur final. Si tu sais utiliser Unix tu n'es pas dépaysé sous Linux et vice versa.
[^] # Re: Mur
Posté par 007 . Évalué à 1.
Ça fait depuis 9 ans (dans 6 mois, ça fera 10 ans) que j'utilise ce vieux Linux :-)
http://www.linuxjournal.com/article.php?sid=6000(...)
Slackware : juin 93
Linux 1.0 : mars 94 (+ de 10 ans)
[^] # Re: Mur
Posté par 007 . Évalué à 1.
> Unix, même époque que le language C. C-à-d fin 60 début 70.
Début développement. Premières versions vraiment exploitables en 73-75.
[^] # Re: Mur
Posté par Mr F . Évalué à 2.
Selon ta définition, non.
C'est SGML en plus simple et SGML date de 15 ou 20 ans (j'ai oublié).
Pour css, la séparation de la présentation et des données est un très vieux concept aussi.
Alors ce n'est pas moderne :-)
Rires...
Unix, même époque que le language C. C-à-d fin 60 début 70.
D'ou le au moins, la recherche de date n'est qu'une vague recherche sur google dont j'avais la flemme. C'est donc dire si vraiment c'est vieux...
L'informatique en est encore à ses débuts. Au début de l'aviation ou de l'automobile, 14 ans c'était énorme aussi.
Tu peux aussi affirmer que l'avion n'est pas un mode de transport moderne alors.
ça dépend, l'avio a réaction oui, l'avion à hélice un peu moins :)
En fait, très peu. En tout cas pour l'utilisateur final. Si tu sais utiliser Unix tu n'es pas dépaysé sous Linux et vice versa.
Il s'agit d'avantage de concept concernant la gestion matériel etc, pas concernant l'aspect end user.
[^] # Humour
Posté par Le Pnume . Évalué à 1.
[^] # Re: Humour
Posté par gnumdk (site web personnel) . Évalué à 1.
Oui, mais Windows 2000 n'a rien de moderne ;) Un pseudo µkernel avec tout et n'importe quoi dedans. Quand tu entends des gens de chez Microsoft dire que la difference entre X et GDI, c'est que X est un programme comme les autres sous Linux alors que GDI "est en mode noyau" (veridique, si quelqu'un a tjs le lien de l'interview du mec de chez MS, passé sur OSnews je pense).
Donc win2k, OS moderne, ah ah ah :)
Tu aurais dit QNX, ok, j'aurais rien dit ;)
[^] # Re: Humour
Posté par Le Pnume . Évalué à 1.
[^] # Re: Humour
Posté par olivn . Évalué à 3.
[^] # Re: Conseils ?
Posté par 007 . É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: Conseils ?
Posté par 007 . É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 . É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 gnumdk (site web personnel) . Évalué à 3.
Quand je dis ca il faut comprendre un crash(coupure de courant le plus souvent) a un moment ou le pc etait actif(urpmi en fonctionnement, ...).
Avec reiserfs et xfs, meme si j'ai eu quelque probleme, c'etait rarement dramatique. Le seul truc que je peux dire, c'est que le plus rapide pour relire son journal, c'est xfs par contre :)
Actuellement j'ai tout en xfs et mon / en reiserfs : le suse 9.1 a un probleme avec xfs et son noyau d'install.
[^] # Re: Conseils ?
Posté par itstimetogo . É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: Conseils ?
Posté par p0l1uX . Évalué à 5.
- debugfs.reiser4
- cpfs.reiser4
- fsck.reiser4
- measurefs.reiser4
- mkfs.reiser4
- resizefs.reiser4
Donc, si, reiserfs v4 a un fsck, et pour répondre à d'autres questions, si il a aussi un resizefs.
Par contre au vu des derniers commentaires sur la ML du kernel, il y a beaucoup de problèmes potentiels (par exemple reiser v4 ne respecte pas le comportement du flag O_DIRECTORY sur un open(), ce qui peut être TRES génant).
[^] # Re: Conseils ?
Posté par Nÿco (site web personnel) . Évalué à 4.
Euh... je sais pas de quoi tu parles là... (et je pense ne pas être le seul... ;-) Tu peux nous en dire plus stp ? Quelles sont les implications/incompatibilités ?
[^] # Re: Conseils ?
Posté par Nÿco (site web personnel) . Évalué à 3.
[^] # Re: Conseils ?
Posté par itstimetogo . É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 p0l1uX . Évalué à 3.
Tout a fait !
Je suis d'ailleurs bien surpris de voir que reiserfs v4 "sort" officielement, alors qu'aucun test serieux effectué par les developpeurs du noyau n'a été fait (par test serieux je n'entends pas test de perfs, mais plus test de fonctionnalités et revue du code).
Il semble aussi que reiser v4 a été developpé sans aucune coordination avec les autres filesystems, et surtout sans respecter les API. C'est pour cette raison que plusieurs developpeurs ont demandé que cette version ne soit pas intégrée au noyau tant que les problèmes ne sont pas corrigés.
Honnetement je doute que reiser v4 soit plus utilisable que pour du test en ce moment, en tout cas je ne l'utiliserait pas en prod :)
[^] # Re: Conseils ?
Posté par patatorz . Évalué à 2.
- j'ai mis /usr et /usr/local en ext2, mais en ro seulement !
comme ca, meme en cas de plantage, pas de pb puisque le fs est en ro.
+ avantage : comme la plupart des soft et lib sont sous /usr et que ext2 est plus rapide, ca se lance "en principe" plus vite; mais surtout, en cas de plantage, ca évite de corrompre quoi que ce soit
- inconvénients : avant d'installer un truc sur /usr, il faut faire un mount /dev/xxx /usr -o remount,rw et aprés l'install, un mount /dev/xxx /usr -o remount,ro
- xfs sur les autres partoches
[^] # Re: Conseils ?
Posté par Olivier Jeannet . Évalué à 3.
comme ca, meme en cas de plantage, pas de pb puisque le fs est en ro.
Dans le temps où seul ext2 existait, j'avais aussi fait comme toi (montage en RO) pour éviter un fsck long et inutile, sur une partition où j'écrivais très peu (inutile dans le sens où le FS n'avait pas été démonté proprement, mais que la structure était intègre, vu qu'aucune écriture n'était en cours au moment de la coupure).
Cela dit, tant que tu n'écris pas sur tes partitions /usr et /usr/local, tu ne peux pas les corrompre, autant les laisser en RW (et ext3). Ca t'évitera de faire les remount et surtout d'y penser. En ext3 les performances en lectures sont les mêmes qu'en ext2, si je ne m'abuse. Maintenant qu'on a ext3 et qu'on évite un long et inutile fsck, je laisse mes partitions /usr et /opt en RW.
# Incohèrences de versions
Posté par un_brice (site web personnel) . Évalué à 2.
Je suppose qu'ils ont voulu limiter la redondance du patch, mais c'est mal fait.
Aussi, le patch est prévu pour un 2.6.4 mais ne semble pas s'appliquer trop mal sur les kernels récents (seulement quelques REJECT pour 2.8.1, et faciles à corriger).
[^] # Re: Incohèrences de versions
Posté par ribwund . Évalué à 2.
# Innovations...
Posté par Pierre Jarillon (site web personnel) . Évalué à 10.
La structure de reiser4 a une certaine parenté avec celle d'une base de données et la place occupée par les tout petits fichiers est optimisée.
Ainsi le courrier stocké sous forme de mail-dir est beaucoup mieux géré par reiser4 que par ext2.
Cette version majeure est donc sortie avec un an de retard sur la date initialement prévue et c'est très bien ainsi. En effet, nous avons déjà de bons systèmes de fichiers, fiables et opérationnels. Il n'y avait donc aucune urgence. Nous ne sommes plus à lépoque de Rémi Card créant ext2.
Nul doute que le code a été soigneusement testé et debuggé pendant cette année. Reiser4 ne peut s'imposer que s'il est meilleur que les autres FS et d'une fiabilité au moins aussi bonne. C'est à dire que la barre est placée très haut et que Hans Reiser n'a pas le droit de se planter.
Comme la perfection n'est pas de ce monde, Hans est obligé de prendre quelques précautions quant à la stabilité car reiser4 n'a pas encore été testé sur plusieurs millions de machines. Il y aura bien quelqu'un qui trouvera un problème après avoir redimensionné à chaud une partition LVM sur du raid logiciel utilisant un disque SATA et un Firewire IEEE1394.
En résumé, je pense que l'on peut utiliser en confiance reiser4 chez soi. Si c'est pour équiper une machine critique, ce n'est pas forcément un choix très judicieux.
[^] # Re: Innovations...
Posté par Nÿco (site web personnel) . Évalué à 4.
Celà dit, il est vrai que les côtés innovants voire "révolutionnaires" de ReiserFS font quand même la fierté d'une partie de la communauté Libre/OpenSource...
[/sérieux>
Tout de même Pierre, je trouve pas très ambitieux : RAID + LVM est un grand classique gagnant du monde GNU/Linux, même si c'est sur du SATA+Firewire... Ne préfèrerais-tu pas essayer ReiserFS4 sur un ENBD sur du RAID 0+1 avec une couche EVMS par dessus, le tout dans un InterMezzo, Coda, ou OpenAFS ? Ce serait bien plus innovant !... Une bière à celui qui mets ça en place chez lui. Une bouffe, s'il nous fait un retour d'expérience concis rédigé dans son journal ! ;-)
http://www.tldp.org/HOWTO/Software-RAID-HOWTO.html(...)
http://tldp.org/HOWTO/LVM-HOWTO/(...)
http://freshmeat.net/projects/enbd/(...)
http://freshmeat.net/projects/evms/(...)
[^] # Re: Innovations...
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
J'ai même l'impression que reiser4 est une étape importante. Les FS : XFS, JFS et NTFS sont maintenant dépassés par une solution libre. J'ai même l'impression qu'aucune concurrence ne viendra plus lui contester sa suprématie. En effet JFS et XFS qui sont maintenant OpenSource (ou mieux, je n'ai pas vérifié) ne seront certainement plus développés si une solution performante et fiable est disponible. Economiquement, IBM n'a aucun intérêt à investir dans un super JFS et SGI encore moins pour XFS.
L'inconnue est pour Microsoft qui a les moyens financiers de développper un nouveau FS. Mais comme l'adoption d'un FS moderne n'a pas été une priorité (il a fallu attendre XP), il est peu probable qu'un inestissement peu rentable soit fait puisque NTFS fonctionne.
PS : Pour le challenge, je double la mise ;-) lol !
[^] # Re: Innovations...
Posté par pasBill pasGates . Évalué à 8.
Depasses en quoi ?
Les plugin ? Deja dans NTFS depuis des lustres
Optimisation pour petits fichiers ? Deja dans NTFS depuis longtemps(ils vont dans la MFT, n'utilisent pas de clusters)
...
Et je serais pas surpris du tout que XFS ou JFS soient dans le meme panier.
Je crois surtout que tu t'es laisse impressioner par une page pleine de mots techniques et un manque de connaissance des autres FS
Et il y a une autre chose qu'il ne faut pas oublier, c'est que les features d'un filesystem sont totalement inutiles si rien dans les couches du dessus ne les utilise, il faudra du temps pour voir si les couches hautes de Linux se mettent a supporter les extensions de ReiserFS
[^] # Re: Innovations...
Posté par Jean Roc Morreale . Évalué à 3.
[^] # Re: Innovations...
Posté par 007 . É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: Innovations...
Posté par 007 . É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 itstimetogo . É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 :-)
# Convertibilité
Posté par Mathieu Gollain-Dupont . Évalué à 2.
[semi-troll]
Je n'ai pas vu cette fonctionnalité sur la page de Reiser4, donc j'imagine qu'elle est inexistante.
Mais je ne pense pas qu'une telle opération soit impossible, car Microsoft fournissait systématiquement un outil pour convertir les systèmes de fichiers de ses partitions en la version la plus récente (FAT16 -> FAT32 pour Windows 98 (ou ME), FAT32 -> NTFS pour Windows XP).
[/semi-troll]
[^] # Re: Convertibilité
Posté par Bertrand Jacquin (site web personnel) . Évalué à 8.
Will it be possible to read/write ReiserFS partitions created now with future versions of ReiserFS?
Yes. ReiserFS-3.6.x (Linux-2.4.x) works with both the old (3.5) and the new (3.6) formats. ReiserFS-3.5.x (Linux-2.2.x) can only work with the old (3.5) disk-format. There is no way to convert the new (3.6) disk-format to the old (3.5), but the old (3.5) format could be converted to the new one (3.6) with the "-o conv" mount option.
To upgrade from reiserfs V3 to V4, use tar, or sponsor us to write a convertfs.
http://slashdot.org/comments.pl?sid=72530&cid=6540673(...)
[^] # Re: Convertibilité
Posté par tgl . Évalué à 6.
Nan, c'est une bonne question :)
> mais est-il (ou sera-t-il) possible de convertir une partition
> ReiserFS en partition Reiser4
Non (en fait, ces 2 FS n'ont vraiment rien en commun, et la conversion n'aurait rien de plus naturel que vers/depuis n'importe quel autre FS). Il faudra passer par un bon vieux tar.
[^] # Re: Convertibilité
Posté par tgl . Évalué à 1.
[^] # Re: Convertibilité
Posté par Pinaraf . Évalué à 1.
Et ?
Regarde l'exemple donné avant : Microsoft fournissait systématiquement un outil pour convertir les systèmes de fichiers de ses partitions en la version la plus récente (FAT16 -> FAT32 pour Windows 98 (ou ME), FAT32 -> NTFS pour Windows XP)
FAT 16 et FAT 32 sont très proches, c'est sur. Par contre, FAT32 et NTFS n'ont rien en commun. Enfin, je suis sur pour NTFS4 d'XP, pour NTFS3 de NT4 je sais pas je le connais pas...
[^] # Re: Convertibilité
Posté par tgl . Évalué à 3.
# Pous tester
Posté par lezardbreton . Évalué à 2.
cf : http://www.yoper.com/(...)
Je n'ai jamais testé yoper, je ne sais pas ce que ça vaut.
[^] # Re: Pous tester
Posté par gnumdk (site web personnel) . Évalué à 2.
http://www.yoper.com/ss2.html(...) => SAX2
[^] # Re: SAX 2
Posté par ZeroHeure (site web personnel) . Évalué à 3.
voir les licenses sur ftp.suse.com ou les anciennes versions sont dispos
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# Dancing tree ?
Posté par dhaos . Évalué à 10.
Reiser4 le filesystem idéal pour samba ?
# Problème
Posté par CoinKoin . Évalué à 10.
Lorsqu'on tente un open sur un fichier avec l'attribut O_DIRECTORY, l'ouverture réussit toujours, ce qui casse certaines applications utilisant la valeur de retour d'opendir pour certains tests. De plus, certains programmes utilisent directement cet attribut comme optimisation par rapport à l'appel de stat(), et ces applications aussi riquent d'être cassées.
Du coup, je crains fort qu'il n'y ait des problèmes de compatibilité avec ReiserFs...
Et ce n'est malheureusement pas le seul problème. Pour plus de détails : http://www.uwsg.indiana.edu/hypermail/linux/kernel/0408.3/0211.html(...)
# Récupération d'un fichier supprimé
Posté par dactar (site web personnel) . Évalué à 2.
Est-ce également le cas avec RaiserFS ?
PS : Oui les backups c'est bien, mais il a toujours été difficile de récupérer un fichier binaire créé il y de cela quelques heures.
[^] # Re: Récupération d'un fichier supprimé
Posté par CoinKoin . Évalué à 2.
Indépendamment du système de fichiers, tu peux toujours faire :
cat /proc/kcore > /tmp/mon_fichier (en root),
puis strings /tmp/mon_fichier | less
Pour essayer de récupérer le source. Si tu n'avais pas le(s) fichier(s) source, c'est plus difficile, mais il faudra que tu m'expliques comment tu crées des binaires sans source :-) .
[^] # Re: Récupération d'un fichier supprimé
Posté par dactar (site web personnel) . Évalué à 4.
Comment créer un fichier binaire sans source ? Installes-toi devant gimp pendant une heure, je suis sûr que tu trouveras.
[^] # Re: Récupération d'un fichier supprimé
Posté par CoinKoin . Évalué à 5.
Un point pour toi :-) .
Et si tu te créais un script du genre :
Tu n'aurais qu'à appeler ce script dans la crontab du root (ou même la tienne), avec exécution toutes les minutes (ln, ça ne coûte rien).
Comme ça, si tu effaces le fichier, et que tu changes d'avis, tu n'as qu'à le récupérer dans /home/save !
Il te suffira alors de faire le ménage dans /home/save de temps en temps (par exemple en utilisant tmpwatch avec un paramètre de 15 jours dans la crontab du root, une fois par jour), et le tour est joué.
Plutôt joli, ce truc, je devrais peut-être le poster comme une astuce sur DLFP. Qu'est-ce que tu en penses?
[^] # Re: Récupération d'un fichier supprimé
Posté par dactar (site web personnel) . Évalué à 2.
Oui pas mal, en plus ça gère les modifications. C'est une jolie astuce de backup minimal. Nécessite :
- Beaucoup d'espace disque si il y a beaucoup de fichiers ou simplement de gros fichiers
- d'appeler le cron très souvent
Ma question première reste ouverte : est-ce que ReiserFS est capable de gérer un recover ?
[^] # Re: Récupération d'un fichier supprimé
Posté par CoinKoin . Évalué à 3.
Hé non, justement! ln fait des liens matériels, donc il ne crée aucun fichier. Bon, il faut quand même de l'espace disque conséquent si on supprime beaucoup de gros fichiers, ou bien énormément de fichiers quelconques, mais sinon, pas besois d'un espace disque particulièrement élevé.
[^] # Re: Récupération d'un fichier supprimé
Posté par dactar (site web personnel) . Évalué à 1.
[^] # Re: Récupération d'un fichier supprimé
Posté par itstimetogo . É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: Récupération d'un fichier supprimé
Posté par CoinKoin . Évalué à 4.
Tout-à-fait exact (encore que ce ne soit pas un comportement rigoureusement conforme POSIX ;-) ). C'est d'ailleurs pour ça que j'ai préconisé l'usage d'un compte /home/save, situé à priori lui aussi sur la partition /home.
Effectivement, si on partitionne /home entre les différents utilisateurs, ça ne marche plus, mais il s'agit à mon avis d'une manoeuvre rare, et dont je ne vois pas vraiment l'utilité.
Sauf s'il s'agit d'imposer des quotas de disque par utilisateur, mais dans ce cas, on peut toujours créer un répertoire ~/../save pour chaque utilisateur.
Je précise qu'il ne faut surtout pas remplacer ln par ln -s dans mon astuce, parce que le lien symbolique ne pointe justement pas les donnéees (si on efface le fichier cible, le lien symbolique pointera "en l'air" et les données seront perdues).
[^] # Re: Récupération d'un fichier supprimé
Posté par gnujsa . Évalué à 3.
C'est du vécu :'(
[^] # Re: Récupération d'un fichier supprimé
Posté par tgl . Évalué à 3.
Bref, deux problème, et deux solutions.
[^] # Re: Récupération d'un fichier supprimé
Posté par udok . Évalué à 4.
PS : sinon le ln normal c'est bien pour le cas où tu supprimes un fichier par mégarde mais par contre ça n'empeche pas de sauvegarder régulièrement parce que si tu fusilles ton fichier de l'intérieur, c'est foutu
[^] # Re: Récupération d'un fichier supprimé
Posté par Krunch (site web personnel) . Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Récupération d'un fichier supprimé
Posté par djano . Évalué à 5.
Meme si tu supprimes ton fichier dans ton répertoire courant, tu supprimes pas reelement le fichier.
Tu supprimes l'entree du fichier dans ton répertoire, mais l'inode du fichier existe encore et tu pointes dessus avec ton lien.
Donc le fichier n'est pas détruit et cela la place qu'il occupe sur le fs n'est donc pas libérée.
Je me dis que j'aurais du mieux suivre les cours sur le buffer cache et les inodes et les liens....
So, j'ai dit une connerie ou pas?
[^] # Re: Récupération d'un fichier supprimé
Posté par itstimetogo . É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 CoinKoin . Évalué à 4.
Et encore, uniquement quand le nombre de processus qui ont ouvert ce fichier tombe lui aussi à 0.
[^] # Re: Récupération d'un fichier supprimé
Posté par itstimetogo . É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 CoinKoin . Évalué à 3.
Merci pour l'astuce :-) .
[^] # Re: Récupération d'un fichier supprimé
Posté par djano . Évalué à 2.
En tout cas, je pertinente tout le monde (dont toi).
Ce vocabulaire me rapelle l'universite, les bancs, toussa, la glande koi, ...
Snif!
Bref merci pour cette demonstration au poil!
[^] # Re: Récupération d'un fichier supprimé
Posté par Krunch (site web personnel) . Évalué à 5.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Récupération d'un fichier supprimé
Posté par fouinto . Évalué à 1.
Est ce que ça aurait quelque chose à voir avec libtrash?
http://pwp.netcabo.pt/0154115101/software/libtrash/(...)
(
je n'ai pas essayé, jai juste fouillé google)
[^] # Re: Récupération d'un fichier supprimé
Posté par Lucas Bonnet . Évalué à 1.
[^] # Re: Récupération d'un fichier supprimé
Posté par CoinKoin . Évalué à 2.
La réponse se trouve sur :
http://linuxfr.org/tips/310.html(...)
[^] # Re: Récupération d'un fichier supprimé
Posté par Cook Captain . Évalué à 1.
A quand cette fonctionnalité pour un FS sous Linux ?
[^] # Re: Récupération d'un fichier supprimé
Posté par CoinKoin . Évalué à 3.
Tiens, effectivement, je n'avais pas pensé aux fichiers core ;-) .
<Patapé!> - aïe, ouille, je ==>[] .
[^] # Re: Récupération d'un fichier supprimé
Posté par CoinKoin . Évalué à 5.
Il s'agit d'arracher la prise de courant de la machine (sic).
En effet, le kernel cache les données des fichiers (et du système de fichiers) en mémoire centrale, et, dans le cas d'une coupure de courant, il n'a pas le temps de répercuter les derniers changements sur le disque.
Cela dit, c'est vraiment un truc d'extrême urgence. Mais il peut servir.
[^] # Re: Récupération d'un fichier supprimé
Posté par itstimetogo . Évalué à 2.
Ou le bouton reset. Ça m'a déjà sauvé quelques heures de boulot.
[^] # Re: Récupération d'un fichier supprimé
Posté par Dafatfab . Évalué à 2.
Ceci, depuis le kernel 2.6.4 qui fait la difference entre les 2... :-)))
[^] # Re: Récupération d'un fichier supprimé
Posté par tgl . Évalué à 3.
[^] # Re: Récupération d'un fichier supprimé
Posté par itstimetogo . É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).
# Voir le thread "silent semantic change with reiser4" sur lkml
Posté par Thomas Cataldo (site web personnel) . Évalué à 1.
[^] # Re: Voir le thread "silent semantic change with reiser4" sur lkml
Posté par Bubu . Évalué à 1.
A-t-il on bon lien pour résumé le fils qui est énorme, pour ceux qui n'ont pas le temps de tout lire, et qui aimeraient savoir si linux va de l'avant où reste arcbouté sur ses acquis (lire le fs du "futur": ext2 avec un patch pour le rendre journalisé: ext3; ça me rappel la comptabilité 16bits de ...).
Merci.
Bubu.
NB: svp mettre la réponse à la question ci-après, et m'envoyer directement à cette adresse ( nobody@dev.null ) les remarques consernant le fs du futur. Merci encore!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.