Après 2 ans de service, XFS aura eu raison de moi: c'est la troisième fois sous ma mandriva que je perds des fichiers sur mes partitions.
Une fois la config xorg, une fois des fichiers que j'ai à peu près réussi à récupérer, et enfin hier, blocage kernel, extinction brutale parce que j'étais super pressé, et perte d'une partie de ma conf gaimde toute ma conf firefox (heureusement que j'avais une sauvegarde et surtout l'extension bookmarks synchroniser), ainsi que ma conf amule... C'est tout ce que j'ai vu pour l'instant... un xfs_check me dit que tout est ok, xfs_repair ne fait rien...
J'ai l'impression que tous les fichiers en cours d'utilisation disparaissent par magie après un arrêt brutal de la machine. Un de mes potes a aussi perdu sa config gaim il n'y a pas longtemps...
Alors XFS, pour moi, c'est terminé et je pense réinstaller ma mandriva 2006 qui me fait un peu trop de blagues de ce gout depuis ma migration 2005->2006...
Un filesystem journalisé SÛR à me proposer ? ext3 ? reiserfs ? jfs ? Les paris sont ouverts...
PS: ce qui me saoule le plus c'est que ça n'arrive pas si on arrête un windows à la bourrin...
# ext3
Posté par Greg (site web personnel) . Évalué à 5.
ReiserFS me semble le plus rapide, mais j'ai déjà perdu des données lors d'un gros crash disque dur... à la fois j'ai aussi sauvé des données grace à ce systeme de fichier !! Ce qui m'embete le plus à vrai dire c'est la gestion des versions : entre ReiserFS et Reiser4, le changement n'est pas anodin....
[^] # Re: ext3
Posté par Tom D . Évalué à 6.
Je ne suis pas sur de comprendre, pour moi Reiser4 est simplement un nouveau système de fichier, aussi différent de ReiserFS que de XFS, JFS ou FAT...
Il a le même nom parce que c'est le même Hans qui en est le géniteur en chef.
Perso, j'ai opté pour ReiserFS (plus rapide, surtout pour les petits fichiers). Pas de soucis jusque maintenant, mais je pense que Ext3 aurait fait l'affaire aussi.
Tom
[^] # Re: ext3 aussi
Posté par Neo Futur (site web personnel) . Évalué à 3.
et meme s'il est moins rapide qu'un autre, je ne suis pas pret a en changer ;)
"You have enemies? Good. That means you've stood up for something in your life." Winston Churchill
[^] # Re: ext3 aussi
Posté par briaeros007 . Évalué à 4.
jamais de perte mais la partition systeme s'est mis en mode "ro" au milieu et ce sans messages :( .
C'est lors du reboot que j'ai vu que ext3 avait merdé (un check disque de nécessaire)
Sur le meme disque j'ai du reiser4 et il a rien vu (aucun probleme lors du check que j'ai lancé quand j'ai vu ca ;) ).
Bon d'un point de vue experience , l'ext3 est le mieux (comprendre l'ext3 a fait ses preuves).
Mais dire qu'il merde jamais est faux ;)
[^] # Re: ext3 aussi
Posté par wilk . Évalué à 3.
[^] # Re: ext3 aussi
Posté par aurelj . Évalué à 4.
Il y a plus probablement eut un problème matériel lors de l'écriture d'un secteur de la partition.
Et comme tu a gentillement ordonné à ton kernel de remonter la partition en ro en cas d'erreur (via le fstab: errors=remount-ro) et bien il s'est executé docilement.
J'ai également rencontré ce problème une fois, avant de découvrire l'option 'errors='.
[^] # Re: ext3
Posté par Twidi (site web personnel) . Évalué à 0.
Depuis que j'utilise reiserfs, je n'ai plus de soucis, meme en cas d'arret brutal, il rejoue le journal et c'est bon.
A l'utilisation, je vois ext3 comme un truc aussi peu fiable que l'ext2 auquel on aurait rajouté un simili journal pour faire croire que c fiable.
Désolé d'être cru, mais de nombreuses pertes de données (même sans crash ni reboot brutal) ont eu raison de moi...
[^] # Re: ext3
Posté par Twidi (site web personnel) . Évalué à 0.
critiquer=pas bien
vous etes au courant que c'est pas comme ça qu'on avance ?
[^] # Re: ext3
Posté par Anonyme . Évalué à 4.
Je pense que tout ceux qui tripatouillent de l'ext3 et de l'ext2 depuis plus de 5 ans ont du risque doucement, à lire que ces systèmes de fichiers ne sont pas fiables.
Qu'ils ne soient pas parfaits, qu'ils ne soient pas les meilleurs de la galaxie, peu importe.
Ces systèmes de fichiers font tourner des milliers de serveurs sans problème notable. Ils sont fiables.
Et le fait qu'ext3 soit journalisé n'est pas une question de « faire croire ».
# ouai
Posté par Marc (site web personnel) . Évalué à 10.
[^] # Re: ouai
Posté par Anonyme . Évalué à 10.
Ah mais c'est supaire ça, ta machine crash, et XFS décide en plus de virer le contenu de tous les fichiers ouverts, histoire de faire en sorte que ton PC n'ait pas crashé pour rien ! C'est vrai quoi, ce serait con de gaspiller un crash sans niquer le système ou les données. :-)
Plus sérieusement, j'ai déjà eu des pertes de données avec ext3fs sur Mandriva suite à des reboots intempestifs, j'avais même fait un journal rageur sur le sujet. Cela dit, ça fait quelques mois que tout semble aller pour le mieux de ce point de vue là.
[^] # Re: ouai
Posté par Marc (site web personnel) . Évalué à 2.
Ça me fait un peu penser aux gens qui iraient dire que debian unstable est pas stable, que debian ne s'installe pas en deux clics, etc. A lire un peu le site de XFS, on dirait pas qu'ils ont en tête l'utilisateur de desktop.
# Normal, c'est une feature...
Posté par NiCoS . Évalué à 7.
Ils peuvent pas se rater partout quand même... ;-)
[^] # Re: Normal, c'est une feature...
Posté par Anonyme . Évalué à 1.
Je vois que finalement, ext3 n'est pas le seul à rencontrer des problèmes.
[^] # Re: Normal, c'est une feature...
Posté par Nicolas Bernard (site web personnel) . Évalué à 3.
Rien est parfait donc ;-)
[^] # Re: Normal, c'est une feature...
Posté par phoenix (site web personnel) . Évalué à 2.
Heureusement j'ai bidouillé pour utiliser la 2ième FAT et récupérer mes données.
Mais le disque était en lecture seul, car la moindre écriture bousillé des fichiers (allé savoir pourquoi ….)
[^] # Re: Normal, c'est une feature...
Posté par Florent Bayle (site web personnel) . Évalué à 10.
[^] # Re: Normal, c'est une feature...
Posté par un_brice (site web personnel) . Évalué à 5.
Par contre sur le PC de ma maman il a décidé récemment de faire des écrans bleus. Même le CD d'install de windows plantait, alors que la partoche était parfaitement lisible sous linux... comme quoi desfois.
Pour en revenir au sujet, je conseille au gens qui ont des pertes avec leur FS de tenter "smartctl -t long", on a souvent des surprises. Dans ce cas, activation de smart dans l'espoir qu'il réalloue les secteurs, et sinon formatage bas niveau !
Un autre problème peut venir du cache des disques durs : ça sert plus à rien sous Linux (pas à quelques Mo de cache près), et la plupart des fabriquant désactivent l'instruction permettant de le vider pour augmenter leur perfs dans les benchs. Ça contourne le log, et le FS peut rien y faire.
Souvent y'a la ram aussi... enfin pleins de bonnes excuses. C'est vrai que XFS et reiserfs réagissent mal au hardware défaillant de manière chronique mais ils résistent en cas de plantage ponctuel.
En fait, j'ai pas assistée à des corruptions spontané de partitions sans problèmes matériels derrière depuis des versions antidéluviennes du 2.4 . En supposant que ça vous soit réellement arrivé, et de manière reproductible, il ne vous reste plus qu'à faire un rapport de bug.
Pour dire que fat32 est résistant il faut en vouloir... rien que le coup du versionning de nom par checksum sur un octet c'est rigolo... en plus il est pas journalisé, je compte plus le nombre de "scandisk à corrigé une erreur" que tout le monde zappait. Sans parler des perfs, ce truc c'est l'archétype du système conçu uniquement pour la rétrocompatibilité (avec win9x justement).
[^] # Re: Normal, c'est une feature...
Posté par Anonyme . Évalué à 5.
Quand je parle de corruption de système de fichiers et de perte de données, je parle de la moitié de ton home qui a foutu le camp on ne sait où, où de ton système qui est en vrac et refuse de booter parce qu'il ne trouve plus ses petits.
Le message « scandisk a corrigé une erreur » je l'ai vu quelques fois en effet, lorsque j'arrêtais mal Windows 9x, mais cela ne m'a jamais occasionné la moindre perte. Je pense plutôt qu'il s'agissait de fichiers temporaires propres au système. C'est tout de même vachement moins gênant que ce que j'ai pu connaître comme pertes de données sous Linux. Il faut dire que ça faisait un paquet d'années que j'étais sous NTFS, et je m'étais habitué à avoir un système de fichiers en béton armé.
[^] # Re: Normal, c'est une feature...
Posté par un_brice (site web personnel) . Évalué à 3.
Sinon on peut effectivement imaginer que toutes les corruptions aient eu lieu sur des fichiers temporaires...
Cette notion n'a pas de sens, pour le peu que j'en sache.
Un système de fichier peut être journalisé au niveau de la structure du fs (Reiserfs, NTFS, XFS) ou des données (Ext3 mode journal). Dans ces deux cas il est tiendras en cas de chute.
À mon avis, un système de fichier "en béton" ça veut juste dire que tu n'a pas connu de problème à l'époque de ce fs, pour une raison ou une autre, par exemple que ton disque était moins vieux ou que ton grille pain n'était pas backdoré par les extra terrestres.
Ou alors, ta mémoire a des défaut subtils... quoi qu'il en soit ça ton cas particulier n'est pas ce qui m'intéresse, et j'aimerais bien que tu compare les FS sur autre chose que ton expérience personnelle.
Sinon, tu vas sur un forum et tu dit "chez moi ça marche pas". Grosso modo, y'a pas d'autres informations dans ton post.
A un moment tu dit :
Si tu perd des données sans y avoir accédé en écriture dans la minute qui précède, ou la structure des dossiers, c'est que ton matériel est défaillant, je persiste.
Et si tu veut être sûr que tes données ne seront pas corrompues en cas de crash, il existe un moyen, et un seul : le mode journal de ext3, c'est tout.
Ceci dit, je doute que microsoft ait déployé un système semblable par défaut sur ntfs, parce que c'est couteux en perf. Donc je persiste à penser que tes problème ne viennent pas du FS.
[^] # Re: Normal, c'est une feature...
Posté par Anonyme . Évalué à 2.
Sa table de partitions n'étant pas conforme au partitionnement réel du disque, windows écrivait régulièrement à coté de sa partition, bouffant /home et tout ce qu'il faut...
[^] # Re: Normal, c'est une feature...
Posté par Tonton Th (Mastodon) . Évalué à 2.
S'il te plait, tu pourrait expliquer techniquement ce qu'il en est, je vais bientôt mettre en place une machine pour enregistrer énormément de données à toute vibrure, et ce truc sur les caches internes m'intrigue...
[^] # Re: Normal, c'est une feature...
Posté par un_brice (site web personnel) . Évalué à 4.
Je peut répeter le peu que je sait : beaucoup de disques durs, de cartes raid (et, parait-il, Linux à une époque) désactivent les commandes de synchronisation de cache, utilisées par des outils de benchmarks pour faire leur tests.
L'interêt c'est de forcer le bench à utiliser le cache. S'il fait ses tests sur de petits fichiers ça change tout.
Y'a un gars qui a écrit un petit programme pour vérifier si le disque obéissait :
http://www.livejournal.com/users/brad/2116715.html (le warning au début est lié à l'auteur de la news slashdot qui avait mal compris et qui croyais que le programe ne faisait intervenir que le comportement du disque)
D'après lui, un workaround pour certains disques IDE est de carrement désactiver le cache avec hdparm, mais ça marche pas systématiquement.
Le rapport avec les systèmes journalisés c'est qu'à mon avis, si le cache se vide pas, y'a (entre autre) un risque que le réordonnancement des données dans le cache par le disque dur bousille le journal si le système plante au mauvais moment.
J'ai dû lire un truc là dessus mais je sais plus où... désolé.
Ah et puis quand je dit qu'à mon avis les caches servent à rien c'est parce que Linux utilise la ram à la place, qu'il sait aussi réordonancer les écritures mais que lui il triche pas.
... j'espère ne pas avoir dit de bêtises... je retrouve pas toutes mes sources mais ça m'a l'air logique.
Sinon, si tu fait des trucs importants, tu devrais envisager d'utiliser une alimentation de secours.
[^] # Re: Normal, c'est une feature...
Posté par kd . Évalué à 4.
Même l'autre jour, quand je testais ndiswrapper, qui a pourtant fait planter Linux une bonne vingtaine de fois dans la journée. Bon, j'avoue, à chaque fois, le noyau répondait encore au fameux Alt-Syst-S. De temps en temps, j'ai aussi des coupures de courant dans mon immeuble, et je n'ai jamais perdu quoi que ce soit.
[^] # Re: Normal, c'est une feature...
Posté par Pooly (site web personnel) . Évalué à 3.
Sous Windows (NTFS), j'ai souvent vu des fichiers temporaires qui ne veulent plus s'effacer quand un truc à merdé (genre un répertoire aoz123ll/aoz123ll[.....]aoz123ll/aoz123ll )
et des fichiers pourris à la suite d'un reboot aléatoire. C'est le seul FS que je connaisse à pouvoir écrire des trucs qu'il ne peut pas supprimer...
Pour ext2, le pire : une coupure de l'alim de l'ordi _juste_ avant le sync... fatal (surtout lorsque l'on vient de transférer une partition... bye bye !)
[^] # Re: Normal, c'est une feature...
Posté par Gmooron . Évalué à 2.
Généralement un boot en mode sans échec marche cependant ...
[^] # Re: Normal, c'est une feature...
Posté par serge_kara . Évalué à 3.
Compiles et executes ca sous windows 2K ou XP.
Ca te cree un fichier avec un nom non valide et du coup il est impossible a effacer.
Du moins j'ai essaye, bah dieu sais que j'ai pas reussi.
Ya aussi la tache ant recursive qui cree un repertoire et le recopie dans lui meme => ca depasse la profondeur max et dans l'cul lulu aussi.
Ya aussi le bug mythique de l'apercu de l'explorateur qui plante sur un gros fichier et rend la suppression dudit fichier difficile.
[^] # Re: Normal, c'est une feature...
Posté par pasBill pasGates . Évalué à 3.
[^] # Re: Normal, c'est une feature...
Posté par serge_kara . Évalué à 2.
Ca fait un peu bricolo comme solution quand meme...
Cela dit, j'ai quand meme une question, pourquoi windows autorise la creation d'un fichier non valide?
[^] # Re: Normal, c'est une feature...
Posté par pasBill pasGates . Évalué à 5.
Resultat, si tu crees un fichier dans un path qui est plus long que ce que Win32 supporte, t'arriveras pas a l'enlever en utilisant simplement les APIs Win32 vu que les APIs font plein de checks (caracteres du nom sont valides pour Win32, longueur aussi, etc...).
D'ou l'existence de noms canoniques, lorsque l'API voit un nom de ce type, il cherche pas plus loin et le passe a NTFS qui s'en occupera, ce qui permet d'operer sur a peu pres n'importe quel fichier vu que NTFS aura le dernier mot.
Bref, un fichier que tu crois non-valide en general, est en fait un fichier valide pour NTFS, mais invalide pour Win32.
[^] # Re: Normal, c'est une feature...
Posté par SF . Évalué à 1.
Et puis windows le jour ou deux versions consécutives seront capables de lire leurs données respectives... FAT16 étendues sous NT4, limites artificielles de la FAT32... Un super utilitaire pour convertir en NTFS (plus securisée parait-il) mais qui omet de définir les droits d'accès... Des disque dynamiques ou je ne sais quoi dont tu ne peux plus jamais te débarasser... Et vas y que la partition de boot doit être à tel endroit et ci et ça.
Après c'est vrai que l'ext3 c'est pas marrant, on s'ennuie avec.
[^] # Re: Normal, c'est une feature...
Posté par totof2000 . Évalué à 4.
Un super utilitaire pour convertir en NTFS (plus securisée parait-il) mais qui omet de définir les droits d'accès... </>
Et comment il fait pour les deviner tes droits d'acces puisque Fat ne connait pas cette notion?
[^] # Re: Normal, c'est une feature...
Posté par SF . Évalué à 3.
Je ne critique pas vraiment l'utilitaire mais plutôt l'usage commercial qui en est fait. Les machines sont souvent livrées en fat32 avec une info sur 'comment sécuriser' qui amène à un utilitaire qui ne change pas grand chose dans ce domaine, à moins que tu ne penses à revoir les accès...
# EVMS + JFS ?
Posté par Fabien . Évalué à 5.
J'utilise xfs sur un serveur perso (full xfs sur du raid1 software) et je n'ai jamais eu un seul problème avec malgré quelques arrêts brutaux (panne de courant et onduleur mal configuré). De plus, la commande xfsdump est des plus pratiques pour faire des sauvegardes (complètes, incrémentales, ...).
Tu as l'air décidé, tu as envie de changer de FS (et ta distrib, tu la gardes ?) alors je te propose JFS et si le coeur t'en dis, regardes du coté de EVMS.
Je les ai installé sur ma machine perso, EVMS révolutionne la gestion des disques/partitions/... , avec lui, fini les prises de têtes pour gérer un conteneur lvm2 sur du raid1 par exemple ( http://tigrou3tac.org/index.php?current=3&suite=1&ar(...) ).
J'ai donc utilisé jfs comme système de fichiers sur cette machine,evms et jfs provenant tous les deux de IBM. Je n'ai aucun reproche à lui faire, malgré là aussi quelques coupures brutales du PC (surchauffe dûe au ventilateur du processeur qui n'était pas assez puissant), il a toujours réussi à rattraper les erreurs.
Maintenant, quelque soit le système de fichiers que tu choisiras, évites de couper ton OS comme un porc.
JFS: http://jfs.sourceforge.net/
EVMS: http://evms.sourceforge.net/
PS: ce commentaire est une pub pour EVMS
[^] # Re: EVMS + JFS ?
Posté par liberforce (site web personnel) . Évalué à 3.
T'as mal interprété: j'ai arrêté la bécanne, mais le système est resté bloqué sans passer à l'affichage des étapes pour l'extinction...
En gros, il aurait fallu jouer les magic sytem requests, mais j'avais pas le temps et j'ai dû éteindre... Un utilisateur windows qui fait la même chose aura beaucoup moins de problèmes...
[^] # Re: EVMS + JFS ?
Posté par Arnaud . Évalué à 2.
xfsdump est un super outil de dump: il dump tout, même les méta-données, dont les ACLs : très très pratique (en plus, on peut même restaurer les fichiers sur d'autres FS!)
Au lieu de changer de FS, tune ta distrib pour qu'elle s'arrete systématiquement proprement... ou change de distrib (c'est l'hivers ;-)
[^] # Re: EVMS + JFS ?
Posté par liberforce (site web personnel) . Évalué à 3.
Tout le monde parle des options de sync aussi... cékoidon ? C'est juste le flag sync dans le fstab ? Est ce que ça change réellement quelque chose sur un arrêt brutal ?
[^] # Re: EVMS + JFS ?
Posté par Anonyme . Évalué à 1.
[^] # Re: EVMS + JFS ?
Posté par Pooly (site web personnel) . Évalué à 1.
[^] # Re: EVMS + JFS ?
Posté par liberforce (site web personnel) . Évalué à 2.
[^] # Re: EVMS + JFS ?
Posté par Arnaud . Évalué à 1.
1. Tu gardes XFS, qui ne journalise que les méta-data (et pas le contenu des fichiers), et tu deviens raisonnable en faisant des sauvegardes. Avec xfsdump qui fait les sauvegardes incrémentales, en plus, tu ne bouffe pas trop de place ;-). Je te conseille un sauvegarde complète de ton /home par semaine ou mois, et une sauvegarde incrémentale par jour, et tu stockes tout ça sur un p'tit NAS/serveur perso. Bien sur, tu automatises tout dans un p'tit script qui lance le xfsdump au boot et balance le résultat par SSH 'en lieu sur'). Depuis que j'ai automatisé les sauvegardes de mon serveur et que ça marche, loi inverse de murphy oblige, tout mes disques sont devenus super fiables.
2. Tu passes à ext3 en faisant gaffe à ton fstab (option de montage data=journal, voir le très instructif article http://www.gentoo.org/doc/en/articles/l-afig-p8.xml), tant pis pour tes sauvegardes, tu le regretteras :o)
# sync ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: sync ?
Posté par Maz (site web personnel) . Évalué à 2.
[^] # Re: sync ?
Posté par syntaxerror . Évalué à 3.
voir kernel Documentation/sysrq.txt, à imprimer et garder à côté de la machine ;-)
[^] # Re: sync ?
Posté par liberforce (site web personnel) . Évalué à 3.
# Arrete l'informatique
Posté par gnumdk (site web personnel) . Évalué à 3.
J'ai eu reiserfs à une époque chez moi, meme probleme, j'ai perdu des fichiers important à plusieurs reprise, j'etais donc passé à xfs...
Depuis xfs, je n'ai jamais eu un seul probleme, mais voyant que ce n'est pas ton cas, je peux juste te dire ca: un ordinateur n'est pas fait pour être arreter à l'arrache! Si tu veux éviter ce probleme, t'as qu'a mettre tes fs en "sync" :p
Mais quel que soit le fs, tu peux avoir des problemes, c'est tout.
Pour finir, des windows xp avec ntfs completement en vrac :ntldr missing & co, j'en vois plein tous les ans ;)
# FS
Posté par fcartegnie . Évalué à 2.
http://linuxfr.org/tips/387.html
[^] # Re: FS
Posté par Jerome Herman . Évalué à 6.
Il y a 142 Gazillions d'options à la config d'XFS aussi bien au moment de la création de la partition, qu'à l'utilisation. Personellement je n'utilise XFS que pour la capture temsp réel de grosses masses de données (genre frame grabing de tout à réseau à 10Gb/s). Mais je sais que mes options rendent le disque formaté en XFS particulièrement sensible aux interruptions de courant.
# metadata-only journaling
Posté par wilk . Évalué à 5.
Je suis alors tombé sur cet article : http://www.gentoo.org/doc/en/articles/afig-ct-ext3-intro.xml qui explique assez bien le problème et pourquoi ext3 n'a pas ce problème par rapport à reiserfs, xfs et jfs.
# Disque / driver
Posté par oops (site web personnel) . Évalué à 0.
Cela peut également venir du driver de ton disque plus que du FS lui.
De problème de cache etc .....
[^] # Re: Disque / driver
Posté par liberforce (site web personnel) . Évalué à 4.
Donc non, mon expérience tend à accuser le FS..
# Reiser4
Posté par gaston . Évalué à 1.
Bon évidemment, faut se palucher le patch du kernel si on veut l'installer.. et ca c'est CHIANT (enfin y'a pire aussi :)). De plus que je crois qu'il est pas près d'être intégré au noyau en l'état des choses, d'après ce que j'ai pu en comprendre en suivant kerneltrap.org.
# Astuce
Posté par Obsidian . Évalué à 2.
http://linuxfr.org/tips/310.html
[^] # Re: Astuce
Posté par liberforce (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.