Serge Rossi a écrit 632 commentaires

> Qu'est ce que tu as contre TAR ?

Ben imagine un serveur avec des disques de 73 Go avec entre 100 et 150 comptes sur chaque disque.

Maintenant, imagine un utilisateur apelle la Hotline pour dire "j'ai paumé mon fichier qui s'apelle trucbidule.doc (à peu près) et je ne sais plus trop dans quel répertoire il était. Pouvez vous me restaurer celui d'avant hier".

Ben avec restore -i, c'est facile et vite fait de retrouver le fichier et de le restaurer. Avec tar... bon courage !

Bien sur, y'a des softs pour faire ça mais on tombe rapidement dans le commercial alors que dump + restore, c'est parfait.

(ceci n'est pas un exemple théorique :-)

Dans tous les benchs, ReiserFS et ext3 ont chacun des points forts mais je vois une raison essentielle qui fait que sur ma machine perso et aussi sur un serveur, je choisirai ext3 : les backups sur bande.

En effet, tout admin Unix sérieux utilisera essentiellement dump et restore pour ça (tar, n'est franchement pas adapté pour rechercher un fichier dans une bande de sauvegarde et le restaurer).

Or dump et restore sous Linux ne supportent QUE ext2 et ext3, pas ReiserFS.

Même XFS est mieux de ce côté puisqu'on a les commandes xfsdump et xfsrestore filées avec (comme sur SGI).

Pour JFS, je ne sais pas.

Maintenant, peut-être que je ne suis pas au courant et que les commandes reiserfsdump et reiserfsrestore existent mais je n'en ai pas conaissance. En attendant : ReiserFS = inutilisable en prod, sinon pour des cas particuliers.

> Tu veux parler de quelqu'un qui ne toucherait pas sa part du trésor ?

Heeuuu, oublie ça :-)

T'as trop fréquenté Zangdar toi ;-)


Je propose que quelqu'un monte la garde à l'entrée de ce donjon.

Heuuu, -1

Pas besoin d'être un développeur aguerri pour compiler le noyau. Mais si on n'est pas capable d'appliquer un petit patch et qu'on n'a pas envie de se documenter un minimum sur ce qu'on fait, on ne compile pas un noyau !

Compiler un noyau est facile mais pas "foolproof" !

C'est d'autant plus vrai que tous les bugs récents ont été détectés aussitôt et tout les sites de news (dont LinuxFr) en ont parlé aussitôt en indiquant les modifs à faire. C'est quand même pas sorcier !

En plus, un bon paquet des ces "bugs" n'étaient que des fautes de frappe empéchant la compilation, pas des bugs de fonctionnement (une fois la faute de frappe corrigée).

Le 2.4.14 par exemple, une fois viré les 2 lignes en trop dans loop.c (oubliées aprés un changement de nom d'une fonction) fonctionnait très bien.

Si on veut un noyau prémaché et testé corrigé de partout, on ne compile pas son noyau soi même, on installe une distrib depuis un CD et on n'y touche plus que pour installer les correctifs officiels.

Si on compile son noyau soi même, on doit être prêt à faire ce genre de modifs, à lire LKML pour y pécher les dernières infos et a "adapter un peu".

C'est comme quand on compile une appli soi-même : "./configure; make; make install", ça ne passe pas toujours du premier coup.

PS : Je suis déçu, aprés "EXTRAVERSION = -greased-weasel" dans Makefile, j'ai été déçu de ne pas trouver ""EXTRAVERSION = -brown-bag" dans le 2.4.16 :-)

Je n'avais pas essayé Galeon depuis TRES longtemps et il ne m'avait pas spécialement plu. C'était un Mozilla allégé mais, sur ma machine, pas spécialement plus rapide et surtout moins stable.

Mais là, je lui ai redonné une chance pour voir et je suis gazé : il est génial ce navigateur !!!

- les préférences des tabs permettent enfin de l'utiliser comme un navigateur en une seule fenêtre (on envoie les popups dans un tab par exemple, bien agréable).
- les champs Google, Freshmeat et RpmFind dans une barre, c'est super.
- la gestion des bookmarks est sympa
- les possibilités de réglage via les préférences sont excellentes.
- il est en Français en plus :-)

C'est aussitôt adopté !

Reste à voir la stabilité sur la durée mais pour l'instant (30 minutes), aucun ennui.

Bon, pour ceux qui sont déjà passé en 2.4.15 (comme moi), pas de panique. Linux ne corrompt pas les FS pendant l'utilisation, il y a juste un risque de perte au démontage des volumes.

Pour migrer au mieux, recompiler le noyau 2.4.15 avec le patch indiqué dans la news (ou un 2.4.14-pre8 ou avant).

- Passer en single user (init 1)
- taper sync pour mettre sur disque tout ce qui
est éventuellement encore caché en mémoire
- immédiatement démonter tous les FS qui ne sont
pas indispensables (tout sauf / quoi)
- rebooter avec le noyau corrigé.

Au pire, forcer un fsck sur tous les FS corrige les éventuels problèmes (rien de spécial chez moi).

Que les développeurs qui n'ont jamais découvert de bugs dans leur appli aprés une mise en prod leur jettent la première pierre :-)

Si tu veux comprendre pourquoi Ext3 roulaize plus les autres (dont XFS), lis donc ce petit article très bien fait par IBM :

http://www-106.ibm.com/developerworks/linux/library/l-fs7/(...)

Pour résumer : journaling des metadata ET des données plus physical journaling contre metadata seulement et logical journaling pour les autres.

Y'a quand même un truc important dans les amliorations apportées par le noyau 2.4.15 :

Ext3 est maintenant intégré en standard !

Rappel pour les ceusses qui n'auraient pas suivi : ext3 est un système de fichiers journalisé, c'est à dire bien plus résistant aux coupures de courant intempestives. Dans ce cas, non seulement ext3 assure une meilleure intégrité des données sur le disque mais il supprime le besoin de faire un fsck au redémarrage suivant. Au remontage du FS, le noyau a juste besoin de "rejouer" le journal sur le disque pour le restaurer en bon état.

A noter aussi que, contrairement aux autres FS journalisés (ReiserFS, JFS, XFS), ext3 peut journaliser non seulement les modifications sur les métadonnées mais aussi sur les données elles mêmes.

Autre avantage non négligeable : la migration.

Avec une version récente de e2fsprogs (1.20 au moins et non 1.19 comme c'est marqué dans Documentation/Changes), il suffit de taper tune2fs -j /dev/partition (hda1, sda1...) pour créer un journal sur le filesystem ext2. Pas besoin de le démonter pour ça.

Au remontage suivant du disque, il sera monté en ext3 (penser à modifier /etc/fstab en conséquence).

Il y a un micro noyau plus répandu : Mach.

En version 2.5, il faisait tourner NextStep sur les superbes stations NeXT.

En version 3.0, il a d'abord fait tourner MkLinux (Micro Kernel Linux) et maintenant, MacOS X/Darwin.

Pour migrer de ext2 vers ext3, il suffit de taper "tune2fs -j .dev/partition" pour créer un journal (c'est instantanné et peut être fait sur la partition montée) et au montage suivant de la partition, on sera en ext3.

Pour migrer de ext2 vers les 3 autres, il faut backuper toutes les données, reformater la partition en JFS/XFS/ReiserFS puis restaurer les données.

Y'a un autre avantage : une partition ext3 peut encore être remontée en ext2 par un ancien noyau qui ne comprends pas le ext3. Ca n'est évidement pas le cas avec les 3 autres.

Tout simplement parce que l'intégration de xfs dans Linux est à un état d'avancement bien moindre que l'intégration d'ext3.

Dans la dernière mise à jour de son agenda journalier, Alan Cox a posté un petit mot qui explique tout sur les récentes rumeurs, la VM, le mainteneur, etc :







Marcelo accepted the chance to become 2.4 maintainer. This is good news because Marcelo is bright, keen and as he is working for a vendor has an understanding of QA issues. This should work out well.







Posted an announcement to Advogato which then mysteriously propogated everywhere else, and also mutated along the way to include a most bizarre eWeek "kernel fork narrowly averted" story and some slightly saner coverage.







The great VM dispute really isn't. It went something along the lines of "Putting a new vm in 2.4.10 is crzy", "Probably it was but its done so lets make it work" and at 2.4.14pre8 "See it works" "Yep".







I guess that doesn't make such exciting journalism however as stories that Linus forced the choice of Marcelo and so on - in fact both of us picked on Marcelo independantly.







Excellent :-)

Linus Torvalds et Alan Cox viennent de se mettrent d'accord sur le choix de la VM pour le noyau Linux qui sera effectivement celle apparue depuis le noyau 2.4.10.







Rik Van Riel (l'auteur de l'ancienne VM) a lui même admis que la nouvelle était meilleure.







http://www.zdnet.com/zdnn/stories/news/0,4586,2822789,00.html(...(...))">http://www.zdnet.com/zdnn/stories/news/0,4586,2822789,00.html(...(.(...)))">http://www.zdnet.com/zdnn/stories/news/0,4586,2822789,00.html(...(...)">http://www.zdnet.com/zdnn/stories/news/0,4586,2822789,00.html(...(.(...))">http://www.zdnet.com/zdnn/stories/news/0,4586,2822789,00.html(...(.(...))))











PS : Je n'ai pas posté ça comme une news car c'est rattaché à la discussion sur le noyau 2.4.14.



Même si la discussion sur cette news est quasiment finie, ce message suffira.

Surtout que même dans les annonces ici comme sur Slashdot, y'avait un lien vers le message expliquant quelles lignes effacer en même temps que l'annonce du noyau.

BTW, ça y'est, c'est compilé installé redémarré (avec les patchs ext3 + premptible kernel) et ça roule. La VM tient le choc pour les quelques tests rapides que j'ai fait (ouvrir une image de 400 Mo dans The Gimp sur une machine de 256 Mo avec en plus Nautilus, Mozilla, Netscape et quelques autres + Seti@Home en tache de fond) et pas un signe de ralentissement dans les temps de réponse, ça me va.

Reste à voir la stabilité sur la durée.

C'est le bon patch, c'est juste que je ne l'avais pas remarqué... ou qu'il est sorti depuis :-)

make dep clean bzImage modules modules_install... :-)

Wahou, le patch pour intégrer ext3 au 2.4 est déjà sorti (il faut dire que depuis la stabilisation de la VM, c'est plus facile de porter ce patch d'une version vers la suivante) :

http://www.uow.edu.au/~andrewm/linux/ext3/(...)
http://www.zip.com.au/~akpm/ext3-2.4-0.9.15-2414.gz(...)

Le Changelog d'ext3 :

0.9.14
------

- Removed much debug code. Minimized core kernel changes as much as poss.

- Move /proc/sys/fs/jbd-debug control up into jbd itself.

- Removed i_truncate_sem, in favour of leaving the orphaned pages on the
inactive_dirty LRU rather than swapping them out.

0.9.15
------

- oops. No change from 0.9.14 :)


Je n'attends plus que le premptible kernel patch pour recompiler tout ça :-)

http://www.tech9.net/rml/linux/(...)

Au boulot, sur un Athlon 1 GHz, j'ai le ventilo du radiateur (un Chrome Orb) qui a cassé (classique, un radiateur *Orb, ça finit toujours par péter). Comme c'était une machine dans un bureau tournant tout le temps, elle a du rester comme ça tout un week end. Le Lundi, j'ai changé le radia, je me suis à moitié cramé les doigts tellements c'était brulant ! La bécanne est repartie, le CPU n'a pas cramé.

Si tu as cramé le CPU sur ta carte mère, c'est que le radiateur devait être mal fixé, c'est à dire appuyant "de travers" sur le core du Duron, ça n'est pas possible autrement.

J'ai eu le même problème chez moi (encore un Orb qui casse) sur un Athlon 1100 MHz. Je m'en suis apperçu au bout de une minute et là non plus, pas de dégats sur le CPU.

J'en profite pour glisser une petite recette de cuisine :

Comment transformer un Orb cassé en ventilateur efficace et solide :

- vire le ventilateur interne
- coller à la Superglue un bout de grosse durite du diamètre extérieur de l'Orb et de 3 cm de long au sommet du radiateur
- coller un ventilateur de boitier au sommet de la durite, soufflant vers le bas, c'est à dire dans le centre de l'Orb.

Résultat, la manip coute 60 balles, ça fait moitié moins de bruit (un ventilo de boitier tourne aux environs de 3500 tours au lieu des 7000 tours d'un petit ventilo) et ça souffle beaucoup plus fort que le ventilo d'origine. Mon CPU en charge (Seti@Home) est passé de 54°C à 44°C !

4 news XP et une news MSN sur la home page, ça fait beaucoup trop sur un site qui s'apelle LinuxFr.

C'est pour ça que je dit qu'on ne voit que des news XP !

Oui, mais de là à ne voire que des news XP !

Moi, je préfère largement voir les news de nouvelle version du kernel Linux en home page et les news XP dans la boite autres, ça serait plus logique et ça collerait un peu mieux avec le nom du site !

Sans oublier que la news sur la sortie du 2.4.13, elle a généré pas mal de conversations à mon avis intéressantes (enfin du genre que je m'attends à trouver sur LinuxFr).


Sinon, pour faire couleur locale : on a testé Windows XP Pro au boulot et il a freezé au bout de 30 minutes.

Comme l'affirme MS, XP est bien la convergence entre la branche NT (pour l'aspect fouilli et tordu de l'interface) et la branche 9x (pour l'instabilité) : merci MS :-)

Sur un vieux PC muni d'un BIOS tout pourri (carte mère PCChips de 1997), je n'ai jamais réussi à faire fonctionner Lilo avec les 2 seuls disques SCSI sur une carte Tekram. A chaque fois, c'était LI seulement et ça n'est jamais allé plus loin.
J'ai été obligé de mettre un petit disque IDE de récup dedans pour le /boot pour m'en tirer.

Avant-hier, ce disque IDE est mort. J'ai réinstallé la RH 7.2 (ça tombait bien) sur les 2 disques SCSI avec Grub et là, ça boote sans problèmes :-)
En plus d'être plus joli et plus pratique, Grub supporte les configs tordues : que des avantages :-)

J'ai évidement essayé uhci mais, en plus d'être infiniment lent quand ça marche, ça bloque pareil.

C'est pour ça que je commence vraiment à croire que le pb vient du chipset VIA.

Note : je n'ai jamais eu de freeze de kernel, ni avec usb-uhci, ni uhci. Par contre, une fois le message de timeout, le bus USB devient inutilisable.

Une autre connerie que je voens juste de trouver avec les chipset VIA.

Ca fait 2 semaines que j'essaye de faire fonctionner un lecteur de Compact Flash USB (Sandisk Imagemate II SDDR 31) et avec mon PC Athlon + VIA KT133 + VIA 686B, à chaque fois que je lis les données, ça se termine avec un message du kernel my "usb_control/bulk_msg: timeout" et un blocage du bus USB qui nécessite un reboot pour le récupérer.

J'ai fouillé partout, lu et écrit dans la ML linux-usb, sans trouver.

Suite à la discussion sur VIA ici-même, ça m'a donné l'idée d'essayer sur un vieux PC (bi PII 266 + chipset Intel 440 LX), juste pour voir. Le tout avec la même distrib, le même noyau compilé tout pareil et paf, comme par hasard, le lecteur fonctionne parfaitement, pas une erreur : Rhaaaa !

Ma prochaine bécanne ne sera pas à base de VIA... à moins qu'un miracle arrive et que VIA publie les specs et "particularités" de ses chipsets pour intégration dans le noyau... mais c'est peu probable !

Bon, pour le SiS 735, quand on va dans les sources du noyau dans :

drivers/ide/sis5513.c

ça cause du SiS 735 et il ne semble pas y avoir de cas particulier de traitement donc ça doit tourner...

Dans lkml, y'a eu un message d'un mec qui avait un pb avec mais ça semblait un pb de cable...

http://www.uwsg.indiana.edu/hypermail/linux/kernel/0109.0/0601.html(...)

Bon, sur Toms Hardware, y'a même un benhmark donc ça marche :

http://www6.tomshardware.com/mainboard/01q2/010611/sis-10.html(...)