La liste des options proposées est volontairement limitée : tout l’intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix.
Les réponses multiples sont interdites pour les mêmes raisons.
Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées ou de l’impossibilité de choisir plusieurs réponses.
76,78 % des personnes sondées estiment que ces sondages sont ineptes.
En l'an de grâce 2004, les barons administrateurs ont soumis un oyez, oyez au bon peuple en le questionnant sur la position de ladite boite de sondage...
C'est l'antépénultienne sondage, sur votre main gauche.
Non car il s'agit d'une utilisation. Et a moins que tu n'utilise qu'exclusivement des live-cd ou tu ne grave 10 cd par jours, à chaque fois que tu te plante devant ton ordinateur tu utilise ta partition principal (au moins).
Moi c'est ReiserFS + LVM2
C'est de la bombe (comme Sabrovitch) !
Ho, une partition pleine, j'ai 5 GO non alloués dans le LVM : pouf, deux commandes et j'ai augmenté la taille de la partition sans la démonter !
Ah moi je reste en LVM1 pour quand je fais une connerie que je puisses recuperer sur ma knoppix :)
maintenant que je reflechis avec le 2.6 de knoppix ptet que
bon je regarderais ca :)
en attendant
reiserfs+lvm powa comme le dit ce cher PieD ;)
Exact!
LVM2 C de la bombe, au lieu de jetter mon ancien disque IDE, j'ai du LVM avec le Nouveau ! et au moins je peux faire autant de partoche que de répertoire!
De plus on rajoute de l'espace disque en 2 commandes (par contre pour en retirer C pas facile..).
Sous Mandrake, l'utilitaire d'installation permet de faire des manips de LVM facillement (voila un argument pour les install graphiques! ) .
Enfin j'utilise du EXT3 car j'ai lu que ReiserFS et XFS étaient bons que sur des diques SCSI (cf: install de gentoo..).
----
Fred
Ben justement, si tu utilisais reiserfs, tu pourrais réduire des partitions facilement, et même sans les démonter ! C'est le seul.
Ext3 peut y arriver mais la dernière fois où j'avais essayer, j'avais du démonter la partition, ça voulait pas.
reiserfs y a que l'agrandissement que tu peux faire a chaud
pas la reduction
mais bon au debut (en general du moins) tu prevois plutot trop petit que trop grand ;)
"
The resize_reiserfs tool resizes an unmounted reiserfs file system. It
enlarges or shrinks an reiserfs file system located on a device so that
it will have size bytes or size=old_size +(-) size bytes if the + or -
prefix is used. If the -s option is not specified, the filesystem will
be resized to fill the given device. The size parameter may have one
of the optional modifiers K, M, G, which means the size parameter is
given in kilo-, mega-, gigabytes respectively.
"
Si il ne pouvait pas rétrécir un système de fichier de type Reiserfs, l'option '-' serait quelque peu inutile, selon moi.
Par contre il me semble bien que le rétrécissement d'un système de fichier de type XFS est plus complexe...
Je voudrais quand même émettre un petit avertissement.
J'ai configuré ma Mandrake 10 Community Ed avec une première couche RAID façon logiciel, puis j'y ai rajouté une 2ème couche LVM2 pour enfin y installer mon ReiserFS.
Bref une bonne petite configuration que l'outil Mandrake a pu me créer de manière facile. Mais il y a 2 hics :
- impossible de booter sur cette configuration sans patcher les scripts init
- l'outil graphique Mandrake ne sait pas relire la configuration énoncée plus haut
En fait, au démarrage, Mandrake détecte d'abord s'il y a des partoches LVM et ensuite soft-RAID. Bref, avec ma configuration, une fois les partitions soft-RAID montées, il faut monter à la main le LVM pour ensuite avoir accès aux données! En touchant les scripts init ça résoud le problème (qq lignes à modifier pas plus) mais c'est chiant. J'ai d'ailleurs ouvert un bug chez Mandrake mais il ne semble toujours pas être pris en compte.
PS: si ça intéresse quelqu'un mon patch, je pourrais l'envoyer sur ce site
Problème mentioné au démarrage du système la partition LVM n'est pas montée : Bug # 8398 (http://qa.mandrakesoft.com/show_bug.cgi?id=8398(...))
N.B.: je n'ai pas réussi à retrouver le bug que j'avais rempli mais il est très similaire au 8398 mentioné ci-dessus (j'utilise le noyau 2.6.3, mais comme le problème est dans les scripts init je ne pense pas que ça ait un impact...). Demain, je rechercherai sur mon autre PC mes emails pour le numéro exact.
Une fois j'ai eu un problème avec ReiserFS v3. Et l'outils fsck pour reiserfs v3 était vraiment pas d'une grande qualité (ce qui était même avoué par les auteurs), résultats perte de fichiers.
D'un autre coté la version 4 est sensé être bien meilleure de ce point de vue là, et d'autres points de vue aussi :-D
Mais tu peux toujours l'utiliser que sur un seul disque à la fois. Tu peux donc utliser un LVM pour chaque disque. Comme ça, si il y en a un qui lâche, bin tu est tranquille.
Sinon tu positionnes en dessous de ton LVM une couche RAID logicielle. Tu y perds un peu de place du fait de la redondance mais tu y gagnes en sécurité, tout en conservant la souplesse et les performances du LVM sur la couche supérieure. Donc si tu as un disque qui lâche, tu remplaces le disque défectueux et tu reconstruits ton RAID et tes données sont toujours là :-)
A toi de voir si tu peux te permettre de te passer d'une partie de tes disques ou non...
N.B.: j'ai fait le test en mettant 3 partitions de mon nouveau disque en RAID 5. J'ai ensuite flingué volontairement une partition avec fdisk. J'ai pu restaurer mon RAID avec une 4ème partition que j'avais laissée afin d'effectuer le test. Ca marche! j'ai rien perdu :-)) Mais bon, le disque n'était pas non plus bondé, j'y avais quelques fichiers seulement de gros volume que j'ai vérifié ensuite avec md5sum pour leur intégrité.
À ce propos, l'un d'entre vous saurait-il si avec LVM et un seul disque dur si avoir un volume physique couvrant tout le disque ou plusieurs volumes physiques (avec des partitions plus petites) est à peu près équivalent ?
J'ai besoin de migrer mes partitions classiques en LVM mais je ne peux pas le faire d'un coup (à cause de choses à sauvegarder).
l' XFS de Sgi est vraiment une bonne fs, je l'utilise sous Linux et Irix et je n' ai jamais eu de problemes avec ... l'ext3 est quand meme tres pratique surtt du cote de la recuperation des donnees (montage en ext2). en ce qui concerne reiferfs j attends la version 4 qui tarde a venir ...
Pour les pros JFS c des cons ... car c'est vraiment une _ _ _ _ _ (cf perfs ...)
boot en 1.30" arret immediat (power off) jamais de journalisation ..... en plus on est 25 au bout du serveur.
Encore mieux : je bosse sur mon ibook -> je rabat l'écran (1 seconde pour se metter en veille) ; je le rouvre (1 seconde pour retrouver mon environement de travail tel que je l'ai laissé). Un reboot tous les 6 mois environ pour upgrader le noyau pour rester à la mode :o)
Et après y en a qui disent que testing c'est pas stable ...
En plus un ibook ca consomme rien (ca sauve la nature, les baleines, toussa) et ca fait pas de bruit et c'est bô.
Oui enfin un suspend-to-ram, en veille, ça consomme quand même et donc tu ne peux pas le laisser comme ça indéfiniment...
Mon portable a 3 ans, je viens de me faire changer la carte mère et l'écran LCD juste avant la fin de garantie, j'espère bien qu'il va me faire 3 ans de plus. Quand ils ont changé l'écran j'ai cru que j'avais un nouveau portable, finalement sans s'en rendre compte les dalles perdent vraiment en contraste/lumière, surtout quand c'est resté allumé non-stop :)
Moi perso je suis en ext3, le power off c'est `sync` et j'appuis sur le bouton.
En plus un ibook ca consomme rien
Et les centaines de litres d'eau qui ont été nécessaires à la fabrication de l'iBook ? Et les kilogrammes de produits chimiques hautement polluants ? Et les métaux lourds dans ton iBook ? Et le pétrole utilisé pour fabriquer le plastique ? C'est pas de la pollution ?
(oui c'est pareil pour n'importe quel ordinateur, portable ou non, mais ça pollue quand même un max à fabriquer, tout ça...)
Oui enfin précisons qu'une fois booté un terminal X utilises le système de fichier natif du serveur directement, sans passer par NFS. Il peut meme booter tout seul son OS sans NFS: avec son propre disque dur ou sur une disquette/CDrom/CF... (ce qui accélère les reboots massifs en cas de grosse panne... sinon le réseau est engorgé par tous les terminaux qui téléchargent en même temps leur OS par NFS) http://www.ltsp.org/(...)
pour les applis c'est vrai faut quitter celle -ci, par contre pour le LTSP
j'ais fait des modifs sur le systeme, mon serveur X est sur chaque terminal reduction de la bande passante + aucun probleme d'authentification . et puis un avantage indeniable par rapport a LTSP toutes les applications tourne sur les terminaux le serveur peut etre un banal PIII . par contre le réseau doit être top 1go pour le serveur sur un switch 1Go/100M.
Je pense donner les modif prochainement en GPL .... wait and See
La dernière fois que j'ai regardé il n'avait pas encore de fsck.
Très génant.
> manque le futur FS par défaut sous linux
Mouaif...
On a déjà lu 50 fois que ReiserFS v3 allait être le FS par défaut de Linux.
Même ici (en France qui utilise moins RedHat/Fedora qui laisse peu de place à ReiserFS) il est 3 fois moins utilisé qu'ext3.
> euh ben ca devait être y'a vraiment longtemps alors...
Reiserfs est en upstream depuis Linux 2.4 (comme ext3). Donc c'est pas vieux.
> les memes fonctionnalités interressante qui font reiser4
reiser4 n'est toujours pas upstream et il manque fsck (ce qui est "grave"). Les attributs attendus ont été ajouté très récement (de façon élégante je trouve et peut-être que d'autres doivent s'en inspirer).
Ce qui manque le plus à ext3 c'est le resize à chaud. Mais un patch existe et Red Hat bosse dessus plus ou moins. C'est présent dans FC2.
Le temps que reiserfs v4 soit complètement débuggué et supporte toutes les "features" les plus classiques il faut encore attendre un bon moment.
Lorsque quelqu'un demande pourquoi Red Hat n'"aime" pas reiserfs, Alan Cox, dont l'indépendance ne peut être mise en doute, répond que c'est car reiserfs ne passe pas les procédures de test Red Hat (en perfo et/ou fonctionnalité, j'ai oublié).
A moins d'être obsédé par les performances, je n'utiliserais pas maintenant. Que ça ne vous empêche pas de l'utiliser au moins pour les tests et faire avancer cet innovant FS.
Perso j'ai jamais eu à me plaindre d'un reiserFS... Je l'utilise depuis la mandrake 9.2 et ce sur toutes mes partitions non win (pour quand j'en avais)
Si ça ne marche pas pour tous les tests tordus de Red Hat ça ne veut pas dire que ça ne marche pour tout le monde.
Sûre que ça marche pour une très large majorité des utilisateurs.
Si ça ne marche pas, ce n'est pas utilisé.
Mais regardes, les statisques. C'est utilisé par beaucoup de monde et donc ça marcher pour beaucoup de monde.
c'est un SF très très robuste, mais par contre il a une défaut majeur!
il bouffe trop de temps CPU dès qu'on lis ou écris(surtout) sur le disque...
A n'utiliser que pour les données sensibles qui ne dopivent pas être perdue en cas de coupure de courant ou autre...
Perso j'ai fait des reset et des freeze kernel et seul le JFS ne me faisait pas perdre de données, la où le ext3, ext2 et reiserFS pouvaient aller se réhabiller (perte de /usr, données sensibles, etc...) ...
> la où le ext3, ext2 et reiserFS pouvaient aller se réhabiller (perte de /usr
Perte de /usr !?!?
dans /usr il n'y a pas décriture normalement.
J'avais des freezes aléatoires sur ma bécane (problème carte mère) et je n'ai jamais rien perdu avec ext3. J'ai de sérieux doute sur ce que tu avances...
Avec des problèmes hard...
J'ai aussi perdu des données avec ext3. Mais toujours pour des problèmes hard (disques vers la fin de vie).
> ça vienais peut-être de la mandrake, ou d'un bug dans le SF ou alors dans le program de gestion de l'ext3 en user mode (utilitaires ext3)
Ça venais peut-être aussi d'ext3 mais c'est rare. Un bug isolé peut toujours arrivé.
Mais je vais te donner un petit exemple.
À une époque il y avait un problème avec ext3. Ben en fait le problème n'était pas ext3 mais le drivers ntfs qui polluait la mémoire du noyau.
Donc il faut y aller avec des pincettes avant d'affirmer :
- "ext3, ext2 et reiserFS pouvaient aller se réhabiller"
ext3 est un FS extrèmement utilisé/testé et reconnu pour sa fiabilité. S'il était "tout pourri" ça se serait.
> la où le ext3, ext2 et reiserFS pouvaient aller se réhabiller (perte de /usr, données sensibles, etc...) ...
Bon troll. Au moins pour ext3.
Trouvé sur mailing Fedora. Un mec a fait plein de tests avec différents systèmes de fichier. http://www.redhat.com/archives/fedora-test-list/2004-July/msg00034.(...) I finally managed to turn off the write caching on the SATA drives (see
patch below) and I have re-run the tests on all four journaling file
systems. And again I am completely stumped by the results.
The test is really pretty simple. It is hooked to a machine that cycles
the power. It runs for 5 minutes and then the power is turned off for
1 minute (to simulate the plug being pulled). For this last set of tests
it has 3 hard drives connected, one Parallel IDE and two Serial ATA. The
system boots a minimal install of Fedora Core 2 from the IDE drive. No
tests are running on the IDE drive. In the rc.local file it starts the
fsstress test http://ltp.sf.net/nfs/fsstress.tgz(...) and the three scripts
below (to simulate writing into a log file) on each of the SATA drives.
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).
I just can't understand what is happening, it makes no sense to me that
one file system would be almost perfect and three would fail so
dramatically. I am going to re-run the tests on all 4 file systems to
verify that it is repeatable.
Should I report these problems to the upstream projects (Reiser, XFS, JFS)?
Réponse/éclaississement d'Alan Cox de ses petites pertes de donnée avec ext3 qui sont "normals" : [...]
Unless you are doing data journalling or some kind of userspace
transactions you wouldn't expect file contents to be perfect. Data
journalling has a big performance cost.
[...]
Your expectations seem at odds with what journalling provides. A journalled
fs can be recovered by log replay. It doesn't guarantee that user data is
recovered precisely. It guarantees that user data is recovered to those
points where it was committed.
Thus
open file O_APPEND
write stuff
close it
repeat. doesn't guarantee "stuff" will always be committed - it just
guarantees that the fs will be structurally sound
open file O_APPEND
write stuff
fsync
close
OTOH says that after the fsync has returned you can be sure the data
just wrote before it *will* still be there.
Ext3 data journalling journals everything which is a bit slower but can
be appropriate for some applications (and actually for big NFS servers
often turns out to be faster because of the NFS commit behaviour)
Réponse de Arjan van de Ven : this is expected behavior; by default ext3 has a journaling mode that is
more safe than defaults of other filesystems, eg when you create a new
file or extend an existing one, it will not commit the new size to disk
before the data has been sent to the disk. Other journaling filesystems
do this entirely asynchronous.
The cost is raw performance, which is why ext3 has a mount option to
emulate the behavior of the other journaling filesystems in both speed
and, ehm, data security.
Your investigation proves that we default to the right mode ;)
Donc : il faut désactiver l'écriture en arrière plan du disque avant de faire des tests !
Sinon ça ne marche pas et c'est un problème connu ! Sauf pour certains disques SCSI.
# j'ai rien à dire
Posté par George Tramo . Évalué à -10.
[^] # MOI SI !!!!!!!!!!!!!
Posté par passant·e . Évalué à -10.
JE VOTE POUR LA POSSIBILITE DE DESACTIVER LA BOITE DES SONDAGES QUI NE ME SERT A RIEN ET QUI ME BOUFFE DE LA PLACE POUR RIEN !!!!
JE VOTE POUR LA POSSIBILITE DE DESACTIVER LA BOITE DES SONDAGES QUI NE ME SERT A RIEN ET QUI ME BOUFFE DE LA PLACE POUR RIEN !!!!
JE VOTE POUR LA POSSIBILITE DE DESACTIVER LA BOITE DES SONDAGES QUI NE ME SERT A RIEN ET QUI ME BOUFFE DE LA PLACE POUR RIEN !!!!
JE VOTE POUR LA POSSIBILITE DE DESACTIVER LA BOITE DES SONDAGES QUI NE ME SERT A RIEN ET QUI ME BOUFFE DE LA PLACE POUR RIEN !!!!
Le comité pour la suppression de la boîte de sondage qui ne lui sert à rien et qui lui bouffe de la place pour rien.
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: MOI SI !!!!!!!!!!!!!
Posté par XHTML/CSS inside (site web personnel) . Évalué à 5.
En l'an de grâce 2004, les barons administrateurs ont soumis un oyez, oyez au bon peuple en le questionnant sur la position de ladite boite de sondage...
C'est l'antépénultienne sondage, sur votre main gauche.
http://linuxfr.org/poll/send,66.html(...)
Vox populi, vox dei !
Et Dura lex sed lex, je sais, je sais...
[^] # Re: MOI SI !!!!!!!!!!!!!
Posté par fab . Évalué à 1.
[^] # Re: MOI SI !!!!!!!!!!!!!
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
# HFS
Posté par Pode . Évalué à -3.
Sinon, ils sont où les symboles /, \/ et X de cette boîte ?
Je n'ai besoin que du "X".
Merci.
--
On finira par y arriver...
[^] # Re: HFS
Posté par Didz . Évalué à 1.
[^] # Re: HFS
Posté par Patrice Lazareff (site web personnel) . Évalué à 2.
# et les *BSD ?
Posté par x0ra . Évalué à 9.
À mince, c'est vrai, on est sur linuxfr.org
[^] # Re: et les *BSD ?
Posté par Victor . Évalué à 6.
# Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ISO9660
Posté par raphulon . Évalué à -1.
[^] # Re: ISO9660
Posté par x0ra . Évalué à -1.
[^] # Re: ISO9660
Posté par Julien Borrel . Évalué à -2.
[^] # Re: ISO9660
Posté par Mr F . Évalué à 6.
# pour moi
Posté par XHTML/CSS inside (site web personnel) . Évalué à 2.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: pour moi
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: pour moi
Posté par Yaz . Évalué à 4.
J'utilise captive avec le noyau 2.6.7 et ça marche.........
[^] # Re: pour moi
Posté par TImaniac (site web personnel) . Évalué à 1.
t'as du bol toi :) tu fais comment ?
enfin trop tard perso j'ai tout passé en FAT32...
[^] # Re: pour moi
Posté par flashball . Évalué à 1.
# LVM powa
Posté par Pinaraf . Évalué à 5.
C'est de la bombe (comme Sabrovitch) !
Ho, une partition pleine, j'ai 5 GO non alloués dans le LVM : pouf, deux commandes et j'ai augmenté la taille de la partition sans la démonter !
[^] # Re: LVM powa
Posté par Ph Husson (site web personnel) . Évalué à 2.
maintenant que je reflechis avec le 2.6 de knoppix ptet que
bon je regarderais ca :)
en attendant
reiserfs+lvm powa comme le dit ce cher PieD ;)
[^] # Re: LVM powa
Posté par anonymous . Évalué à -6.
[^] # Re: LVM powa
Posté par fielog . Évalué à 0.
LVM2 C de la bombe, au lieu de jetter mon ancien disque IDE, j'ai du LVM avec le Nouveau ! et au moins je peux faire autant de partoche que de répertoire!
De plus on rajoute de l'espace disque en 2 commandes (par contre pour en retirer C pas facile..).
Sous Mandrake, l'utilitaire d'installation permet de faire des manips de LVM facillement (voila un argument pour les install graphiques! ) .
Enfin j'utilise du EXT3 car j'ai lu que ReiserFS et XFS étaient bons que sur des diques SCSI (cf: install de gentoo..).
----
Fred
[^] # Re: LVM powa
Posté par Gilles Mocellin . Évalué à 1.
Ext3 peut y arriver mais la dernière fois où j'avais essayer, j'avais du démonter la partition, ça voulait pas.
[^] # Re: LVM powa
Posté par Ph Husson (site web personnel) . Évalué à 1.
pas la reduction
mais bon au debut (en general du moins) tu prevois plutot trop petit que trop grand ;)
[^] # Re: LVM powa
Posté par Gilles Mocellin . Évalué à 5.
Tu as un gros avertissement comme quoi c'est experimental, mais ça le fait !
Je l'ai déjà fait plusieurs fois.
[^] # Re: LVM powa
Posté par Anonyme . Évalué à 1.
[^] # Re: LVM powa
Posté par Ph Husson (site web personnel) . Évalué à 0.
et ce que me dis resize_reiserfs
[^] # Re: LVM powa
Posté par Anonyme . Évalué à 1.
Si il ne pouvait pas rétrécir un système de fichier de type Reiserfs, l'option '-' serait quelque peu inutile, selon moi.
Par contre il me semble bien que le rétrécissement d'un système de fichier de type XFS est plus complexe...
À confirmer
[^] # Re: LVM powa
Posté par Jean-Christophe Berthon (site web personnel) . Évalué à 4.
J'ai configuré ma Mandrake 10 Community Ed avec une première couche RAID façon logiciel, puis j'y ai rajouté une 2ème couche LVM2 pour enfin y installer mon ReiserFS.
Bref une bonne petite configuration que l'outil Mandrake a pu me créer de manière facile. Mais il y a 2 hics :
- impossible de booter sur cette configuration sans patcher les scripts init
- l'outil graphique Mandrake ne sait pas relire la configuration énoncée plus haut
En fait, au démarrage, Mandrake détecte d'abord s'il y a des partoches LVM et ensuite soft-RAID. Bref, avec ma configuration, une fois les partitions soft-RAID montées, il faut monter à la main le LVM pour ensuite avoir accès aux données! En touchant les scripts init ça résoud le problème (qq lignes à modifier pas plus) mais c'est chiant. J'ai d'ailleurs ouvert un bug chez Mandrake mais il ne semble toujours pas être pris en compte.
PS: si ça intéresse quelqu'un mon patch, je pourrais l'envoyer sur ce site
--
Jean-Christophe
[^] # Re: LVM powa
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
[^] # Re: LVM powa
Posté par Jean-Christophe Berthon (site web personnel) . Évalué à 4.
Je n'ai pas mes emails sous la main... Alors après une petite recherche sous bugzilla j'ai retrouvé les numéros en question.
Problème mentioné que diskdrake (l'utilitaire de partition) ne sait pas relire la configuration LVM : Bug #8065 (http://qa.mandrakesoft.com/show_bug.cgi?id=8065(...))
Problème mentioné au démarrage du système la partition LVM n'est pas montée : Bug # 8398 (http://qa.mandrakesoft.com/show_bug.cgi?id=8398(...))
N.B.: je n'ai pas réussi à retrouver le bug que j'avais rempli mais il est très similaire au 8398 mentioné ci-dessus (j'utilise le noyau 2.6.3, mais comme le problème est dans les scripts init je ne pense pas que ça ait un impact...). Demain, je rechercherai sur mon autre PC mes emails pour le numéro exact.
Jean-Christophe
[^] # Re: LVM powa
Posté par drac . Évalué à 3.
D'un autre coté la version 4 est sensé être bien meilleure de ce point de vue là, et d'autres points de vue aussi :-D
[^] # Re: LVM powa
Posté par Yannick (site web personnel) . Évalué à 0.
[^] # Re: LVM powa
Posté par KiKouN . Évalué à 1.
[^] # Re: LVM powa
Posté par Jean-Christophe Berthon (site web personnel) . Évalué à 4.
A toi de voir si tu peux te permettre de te passer d'une partie de tes disques ou non...
N.B.: j'ai fait le test en mettant 3 partitions de mon nouveau disque en RAID 5. J'ai ensuite flingué volontairement une partition avec fdisk. J'ai pu restaurer mon RAID avec une 4ème partition que j'avais laissée afin d'effectuer le test. Ca marche! j'ai rien perdu :-)) Mais bon, le disque n'était pas non plus bondé, j'y avais quelques fichiers seulement de gros volume que j'ai vérifié ensuite avec md5sum pour leur intégrité.
--
Jean-Christophe
[^] # Re: LVM powa
Posté par Fabimaru (site web personnel) . Évalué à 2.
J'ai besoin de migrer mes partitions classiques en LVM mais je ne peux pas le faire d'un coup (à cause de choses à sauvegarder).
# XFS
Posté par izulium . Évalué à -2.
l' XFS de Sgi est vraiment une bonne fs, je l'utilise sous Linux et Irix et je n' ai jamais eu de problemes avec ... l'ext3 est quand meme tres pratique surtt du cote de la recuperation des donnees (montage en ext2). en ce qui concerne reiferfs j attends la version 4 qui tarde a venir ...
Pour les pros JFS c des cons ... car c'est vraiment une _ _ _ _ _ (cf perfs ...)
IzuliuM
# et le NFS ?
Posté par vincent FILALI-ANSARY (site web personnel) . Évalué à 7.
LTSP = Linux Terminal Server Project.
boot en 1.30" arret immediat (power off) jamais de journalisation .....
en plus on est 25 au bout du serveur.
[^] # Re: et le NFS ?
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 2.
T'as bien testé, c'est rapide comme tout ?
[^] # Re: et le NFS ?
Posté par Olivier Grisel (site web personnel) . Évalué à 7.
Encore mieux : je bosse sur mon ibook -> je rabat l'écran (1 seconde pour se metter en veille) ; je le rouvre (1 seconde pour retrouver mon environement de travail tel que je l'ai laissé). Un reboot tous les 6 mois environ pour upgrader le noyau pour rester à la mode :o)
Et après y en a qui disent que testing c'est pas stable ...
En plus un ibook ca consomme rien (ca sauve la nature, les baleines, toussa) et ca fait pas de bruit et c'est bô.
[^] # Re: et le NFS ?
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 1.
Mon portable a 3 ans, je viens de me faire changer la carte mère et l'écran LCD juste avant la fin de garantie, j'espère bien qu'il va me faire 3 ans de plus. Quand ils ont changé l'écran j'ai cru que j'avais un nouveau portable, finalement sans s'en rendre compte les dalles perdent vraiment en contraste/lumière, surtout quand c'est resté allumé non-stop :)
Moi perso je suis en ext3, le power off c'est `sync` et j'appuis sur le bouton.
[^] # Re: et le NFS ?
Posté par Olivier G. . Évalué à 3.
Et les centaines de litres d'eau qui ont été nécessaires à la fabrication de l'iBook ? Et les kilogrammes de produits chimiques hautement polluants ? Et les métaux lourds dans ton iBook ? Et le pétrole utilisé pour fabriquer le plastique ? C'est pas de la pollution ?
(oui c'est pareil pour n'importe quel ordinateur, portable ou non, mais ça pollue quand même un max à fabriquer, tout ça...)
[^] # Re: et le NFS ?
Posté par Christophe Merlet (site web personnel) . Évalué à 0.
[^] # Re: et le NFS ?
Posté par ewasx . Évalué à -1.
[^] # X remote display
Posté par free2.org . Évalué à 1.
http://www.ltsp.org/(...)
[^] # Re: X remote display
Posté par vincent FILALI-ANSARY (site web personnel) . Évalué à 1.
j'ais fait des modifs sur le systeme, mon serveur X est sur chaque terminal reduction de la bande passante + aucun probleme d'authentification . et puis un avantage indeniable par rapport a LTSP toutes les applications tourne sur les terminaux le serveur peut etre un banal PIII . par contre le réseau doit être top 1go pour le serveur sur un switch 1Go/100M.
Je pense donner les modif prochainement en GPL .... wait and See
# manque le futur FS par défaut sous linux ;)
Posté par cedricv . Évalué à 0.
[^] # Re: manque le futur FS par défaut sous linux ;)
Posté par dlfpbot . Évalué à -1.
[^] # Re: manque le futur FS par défaut sous linux ;)
Posté par 007 . Évalué à 0.
Très génant.
> manque le futur FS par défaut sous linux
Mouaif...
On a déjà lu 50 fois que ReiserFS v3 allait être le FS par défaut de Linux.
Même ici (en France qui utilise moins RedHat/Fedora qui laisse peu de place à ReiserFS) il est 3 fois moins utilisé qu'ext3.
[^] # Re: manque le futur FS par défaut sous linux ;)
Posté par cedricv . Évalué à 2.
reiserfs v3 n'a pas les memes performances et les memes fonctionnalités interressante qui font reiser4
[^] # Re: manque le futur FS par défaut sous linux ;)
Posté par 007 . Évalué à 1.
Reiserfs est en upstream depuis Linux 2.4 (comme ext3). Donc c'est pas vieux.
> les memes fonctionnalités interressante qui font reiser4
reiser4 n'est toujours pas upstream et il manque fsck (ce qui est "grave"). Les attributs attendus ont été ajouté très récement (de façon élégante je trouve et peut-être que d'autres doivent s'en inspirer).
Ce qui manque le plus à ext3 c'est le resize à chaud. Mais un patch existe et Red Hat bosse dessus plus ou moins. C'est présent dans FC2.
Le temps que reiserfs v4 soit complètement débuggué et supporte toutes les "features" les plus classiques il faut encore attendre un bon moment.
Lorsque quelqu'un demande pourquoi Red Hat n'"aime" pas reiserfs, Alan Cox, dont l'indépendance ne peut être mise en doute, répond que c'est car reiserfs ne passe pas les procédures de test Red Hat (en perfo et/ou fonctionnalité, j'ai oublié).
A moins d'être obsédé par les performances, je n'utiliserais pas maintenant. Que ça ne vous empêche pas de l'utiliser au moins pour les tests et faire avancer cet innovant FS.
[^] # Re: manque le futur FS par défaut sous linux ;)
Posté par Pinaraf . Évalué à 1.
[^] # Re: manque le futur FS par défaut sous linux ;)
Posté par 007 . Évalué à 1.
Sûre que ça marche pour une très large majorité des utilisateurs.
Si ça ne marche pas, ce n'est pas utilisé.
Mais regardes, les statisques. C'est utilisé par beaucoup de monde et donc ça marcher pour beaucoup de monde.
[^] # Re: manque le futur FS par défaut sous linux ;)
Posté par seeschloss . Évalué à 1.
Vraiment ?
[root@strawberrythingy:~]# fsck.reiser4 --version
fsck.reiser4 0.5.5
Copyright (C) 2001, 2002, 2003, 2004 by Hans Reiser, licensing governed by
reiser4progs/COPYING.
Bon, il faut dire que je n'ai pas encore eu à m'en servir donc je ne peux pas dire si il est efficace, mais en tout cas il est là.
Sinon, je suis surtout reiserfs/xfs.
[^] # Re: manque le futur FS par défaut sous linux ;)
Posté par Ramón Perez (site web personnel) . Évalué à 0.
# swap n'est pas un système de fichier
Posté par Guillaume Knispel . Évalué à 5.
[^] # Re: swap n'est pas un système de fichier
Posté par 007 . Évalué à 1.
[^] # Re: swap n'est pas un système de fichier
Posté par Olivier Serve (site web personnel) . Évalué à 3.
-->[]
# et le HPFS ???
Posté par cce . Évalué à 1.
# JFS
Posté par Christophe Magnani . Évalué à 0.
a+
Tof
[^] # Re: JFS
Posté par Raphaël G. (site web personnel) . Évalué à 1.
il bouffe trop de temps CPU dès qu'on lis ou écris(surtout) sur le disque...
A n'utiliser que pour les données sensibles qui ne dopivent pas être perdue en cas de coupure de courant ou autre...
Perso j'ai fait des reset et des freeze kernel et seul le JFS ne me faisait pas perdre de données, la où le ext3, ext2 et reiserFS pouvaient aller se réhabiller (perte de /usr, données sensibles, etc...) ...
[^] # Re: JFS
Posté par Christophe Magnani . Évalué à 1.
a+
Tof
[^] # Re: JFS
Posté par 007 . Évalué à -1.
Perte de /usr !?!?
dans /usr il n'y a pas décriture normalement.
J'avais des freezes aléatoires sur ma bécane (problème carte mère) et je n'ai jamais rien perdu avec ext3. J'ai de sérieux doute sur ce que tu avances...
[^] # Re: JFS
Posté par Raphaël G. (site web personnel) . Évalué à -1.
ça vienais peut-être de la mandrake, ou d'un bug dans le SF ou alors dans le program de gestion de l'ext3 en user mode (utilitaires ext3)
[^] # Re: JFS
Posté par 007 . Évalué à -1.
Avec des problèmes hard...
J'ai aussi perdu des données avec ext3. Mais toujours pour des problèmes hard (disques vers la fin de vie).
> ça vienais peut-être de la mandrake, ou d'un bug dans le SF ou alors dans le program de gestion de l'ext3 en user mode (utilitaires ext3)
Ça venais peut-être aussi d'ext3 mais c'est rare. Un bug isolé peut toujours arrivé.
Mais je vais te donner un petit exemple.
À une époque il y avait un problème avec ext3. Ben en fait le problème n'était pas ext3 mais le drivers ntfs qui polluait la mémoire du noyau.
Donc il faut y aller avec des pincettes avant d'affirmer :
- "ext3, ext2 et reiserFS pouvaient aller se réhabiller"
ext3 est un FS extrèmement utilisé/testé et reconnu pour sa fiabilité. S'il était "tout pourri" ça se serait.
[^] # Re: JFS
Posté par 007 . Évalué à 4.
Bon troll. Au moins pour ext3.
Trouvé sur mailing Fedora. Un mec a fait plein de tests avec différents systèmes de fichier.
http://www.redhat.com/archives/fedora-test-list/2004-July/msg00034.(...)
I finally managed to turn off the write caching on the SATA drives (see
patch below) and I have re-run the tests on all four journaling file
systems. And again I am completely stumped by the results.
The test is really pretty simple. It is hooked to a machine that cycles
the power. It runs for 5 minutes and then the power is turned off for
1 minute (to simulate the plug being pulled). For this last set of tests
it has 3 hard drives connected, one Parallel IDE and two Serial ATA. The
system boots a minimal install of Fedora Core 2 from the IDE drive. No
tests are running on the IDE drive. In the rc.local file it starts the
fsstress test http://ltp.sf.net/nfs/fsstress.tgz(...) and the three scripts
below (to simulate writing into a log file) on each of the SATA drives.
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).
I just can't understand what is happening, it makes no sense to me that
one file system would be almost perfect and three would fail so
dramatically. I am going to re-run the tests on all 4 file systems to
verify that it is repeatable.
Should I report these problems to the upstream projects (Reiser, XFS, JFS)?
Réponse/éclaississement d'Alan Cox de ses petites pertes de donnée avec ext3 qui sont "normals" :
[...]
Unless you are doing data journalling or some kind of userspace
transactions you wouldn't expect file contents to be perfect. Data
journalling has a big performance cost.
[...]
Your expectations seem at odds with what journalling provides. A journalled
fs can be recovered by log replay. It doesn't guarantee that user data is
recovered precisely. It guarantees that user data is recovered to those
points where it was committed.
Thus
open file O_APPEND
write stuff
close it
repeat. doesn't guarantee "stuff" will always be committed - it just
guarantees that the fs will be structurally sound
open file O_APPEND
write stuff
fsync
close
OTOH says that after the fsync has returned you can be sure the data
just wrote before it *will* still be there.
Ext3 data journalling journals everything which is a bit slower but can
be appropriate for some applications (and actually for big NFS servers
often turns out to be faster because of the NFS commit behaviour)
Réponse de Arjan van de Ven :
this is expected behavior; by default ext3 has a journaling mode that is
more safe than defaults of other filesystems, eg when you create a new
file or extend an existing one, it will not commit the new size to disk
before the data has been sent to the disk. Other journaling filesystems
do this entirely asynchronous.
The cost is raw performance, which is why ext3 has a mount option to
emulate the behavior of the other journaling filesystems in both speed
and, ehm, data security.
Your investigation proves that we default to the right mode ;)
Informations supplémentaires et utiles données par Bill Rugolsky Jr. :
http://www.redhat.com/archives/fedora-test-list/2004-July/msg00036.(...)
Il y a aussi eu un très long thread en avril :
http://www.redhat.com/archives/fedora-test-list/2004-April/msg02646(...)
Donc : il faut désactiver l'écriture en arrière plan du disque avant de faire des tests !
Sinon ça ne marche pas et c'est un problème connu ! Sauf pour certains disques SCSI.
# et si on backup tout sur floppy ?
Posté par XBlaster . Évalué à -1.
le fat12 c l'avenir...
n'empeche... c le format qui doit être le format le plus utilisé dans les administrations ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.