|
Description de la tâche
La MAJ 4.7.5 a résolu bon nombre de problèmes dont la disparition subite du partage SMB qu’il fallait redémarrer manuellement, soit par reboot de la box, soit en décochant / recochant la case partage Windows pour ne redémarrer que Samba.
Les bugs rapportées par de nombreuses personnes ne mentionnaient aucunement des box rendues instables au point de faire rebooter la box.
Il pouvait y avoir de temps en temps des plantages WiFi… mais tout cela a été à peu près fixé
Pourtant certaines personnes continuent de mettre en cause Samba l’accusant de déstabiliser la box même après 4.7.5
Il est manifeste qu’il y a chez ces personnes d’autres problèmes, Samba n’étant pas forcément la cause du problème (comme le persiste encore à le croire trop de personnes naives) mais Samba pouvant planter consécutivement à un autre problème… et dans certains cas on peut penser à des problèmes hard comme l’alimentation. Il y a un fil ouvert par une personne qui a 5 disques durs connectés en USB en plus de ses 4 disques internes… c’est du grand n’importe quoi.
L’USB est un protocole basiquement merdique (firewire était réputé plus fiable), je sais par expérience qu’on connecte un ou deux disques USB grand max, au delà… on a des problèmes. Les disques ont tendance à disparaitre à bugger.
Personnellement c’est jamais plus d’un disque USB par racine USB. Je peux connecter 2 disques USB mais alors sur deux racines USB différentes ce qui implique 2 contrôleurs USB dans la machine.
Je connecte 2 disques simultanément sur la même racine que lorsque je n’ai d’autres solutions mais je sais que je prends alors un risque, celui de pourrir l’un des disques sur une erreur de transfert majeure.
Dans ce cas il est assez facile d’analyser la cause la plus probable du problème : alimentation, les limitations connues du protocole USB
Il se trouve que récemment j’ai eu un plantage majeur de la box, allant jusqu’à planter le Wifi, consécutivement à un accès Samba
Reboot obligatoire de la box
En fait, en investiguant davantage je me suis aperçu que les fichiers sources que je voulais copier en réseau étaient corrompus.
J’avais monté localement une SDCARD formatté en ext4 et suite à ces problèmes j’effectue un “fsck” et la badaboum je me rends compte que le système de fichier était complètement vérolé, d’ailleurs le fsck a abouti à la perte des 3/4 des données car le flag de journalisation n’était pas activé (je ne pouvais pas activer ce flag car c’était du SDCARD dédiée à un système non linux)
Donc par analogie, les gens prétendant que Samba est en cause devraient d’abord faire un check de leur disques locaux, notament sur NTFS il faut lancer la commande “chkdsk /B /r /i” (B et R sonts importants car ils nettoient certaines erreurs qui ne sont pas traitées avec une vérification classique (notamment celle au démarrage de windows, qui n’applique qu’un contrôle “light”) et qui peuvent justement être à la source de ce type de problèmes. Le check est nettement plus long, il faut le cas échéant un redémarrage si on contrôle le système de fichier racine de Windows.
QUI PLUS EST : si le système de fichier distant Samba lui-même est corrompu, ça ne peut aussi que causer des problèmes
En fait les disques internes formattés en EXT4, le FS natif de Linux ne posent aucun problème car la Freebox répare le système de façon silencieuse.
Le problème peut se poser :
1) EXT4
- sur les disques Internes : ceux qui auraient été préparés manuellement par l’utilisateur depuis un poste externe, montés plus tard dans la box, et sur lesquels la journalisation aurait été volontairement désactivée, ou placée à un niveau de journalisation insuffisant (il faut de préférence le niveau de journalisation max soit journal_data).
Sans journalisation Linux ne peut rien récupérer sur certaines erreurs, c’est ce qui m’est arrivé pour ma SDCARD, la règle s’applique aussi à NTFS voilà pourquoi il est dangereux d’utiliser NTFS sur Linux car NTFS sur Linux ne supporte pas la journalisation
Avec la journalisation journal_data (et pas data_ordered qui est insuffisant) on atteint le même niveau de sécurité que NTFS, et on récupére le support dans 99% des situations. Avec une journalisation intermédiaire le taux de récupération tombe à 50%.
Faites un tour sur google et vous verrez les nombreuses personnes qui ont installé Linux sur un poste personnel et qui ont constaté ces pertes aléatoires indignes de la réputation de Linux. J’ai du moi-même dû réinstaller complètement mon système openSUSE qui n’aura pas tenu deux semaines.
Si les distro appliquent par défaut une journalisation intermédiaire (en général data_ordered), c’est pour des raisons de performances.
Or ça n’est valable que sur des serveurs utilisant des cartes SATA professionnelles qui prennent en charge en amont des corrections d’erreurs diverses ce qui permet de libérer le système de fichier local qui peut être en retour plus véloce.
Sur un notebook, un PC, la Freebox, on a affaire à des puces SATA très très bas de gamme…. c’est pour cette raison qu’il faut appliquer une journalisation maximale (journal_data), c’est valable pour n’importe quel OS, j’applique aussi la journalisation maximale GJournal sur UFS FreeBSD, car idem… perte entier de système installés sur des PC, UFS étant le système de fichier serveur par excellence, c’est le FS historique d’UNIX qui impliquait donc à l’origine du “hardware de grande qualité”. Le portage sur x86 a mené les équipes FreeBSD à développer la journalisation GJournal pour que UFS puisse fonctionner correctement sur les PC de monsieur tout le monde apparus plus tardivement après le fameux PC d’IBM.
En fait dans un contexte “serveur” pro, Gjournal n’est jamais utilisé dans le monde BSD (on utilise une journalisation de niveau intermédiaire plus light), beaucoup d’admin pro ignorent d’ailleurs même son existence.
Ca doit être la même chose pour “journal_data” d’EXT4
La perte de perf induite par la journalisation max, dans le cadre d’un poste personnelle, est inquantifiable. C’est juste sur un usage de serveurs intensifs que la perte de perf peut avoir une vraie incidence.
- sur Disques externes : sauf peut-être sur des supports très lents comme des SDCARD de première génération, EXT4 sur disques USB devrait fonctionner sans souci, juste veiller à inscrire dans le superblock l’option de journalisation max, car en fait je ne sais aps quel niveau de journalisation par défaut applique la Freebox si le drive est formatté en interne. Pour cette OP il faudra un poste linux et on passe par la commande tune2fs
Pour des SDCARD il faut sans doute utiliser à minima un équivalent des Sandisk Ultra (et idéalement SanDisk Extrem). Les débits plus confortables conjugués à la journalisation font que je n’ai jamais eu aucun souci…
2) Systèmes exogènes : NTFS, EXFAT
Ces systèmes sont toujours pris en charge par cette grosse M…ERDE de fuse
Je pratique BSD et Linux depuis un certain temps, je PESE MES MOTS fuse c’est de la GROSSE M…ERDE, il m’a causé des problèmes indescriptibles et pas uniquement sur NTFS ou EXFAT, c’est le framework fuse qui est merdique et qui cause des freezes, des plantages
Sur la Freebox v6 j’ai perdu plusieurs systèmes NTFS devenus même irrécupérables sous Windows
A partir de là, les gens qui utilisent des disques USB sur la Freebox en NTFS ou exfat doivent s’attendrent au bout d’un moment à avoir un système de fichier corrompu jusqu’à la moelle.
Il faut régulièrment prendre le drive sous Windows et appliquer un chdsk (et pour NTFS un chkdsk approfondi chkdsk /f /B /r, c’est très important, certaines erreurs ne sont pas corrigées par la procédure standard)
Dans ces conditions pas étonnant que Samba puisse être déstablisé dès lors que le FS est bancal.
La situation s’éclaircira peut-être lorsque la Freebox abandonnera cette escroquerie de fuse pour migrer vers les modules de noyau NTFS3 de Paragon et exfat de Samsung tout deux désormais livrés en standard sur toute distribution Linux récente (juste penser à virer les paquet fuse pour éviter un quiproquo)
3) Stabilisation du serveur Samba
Lorsqu’un poste Windows envoie des données corrompues ça génère rarement un problème grave sur Samba
Parfois un fichier est rendu inaccessible car l’inode du FS distant est verrouillé par le client local Windows
En général un reboot du poste Windows a pour effet de forcer samba à relâcher tous les verrous détenus par ce client, et on peut revenir sur le fichier en partie transféré et le supprimer (on peut aussi redemarrer SAMBA, ça devrait avoir le même effet, à voir)
Dans certains cas, des fcihiers plus récalcitrants doivent être retirés directement depuis l’explorateur de fichier Freebox OS
Avec Linux et MAC OS en revanche ça semble poser des problèmes plus sérieux. Sans doute y a-til de subtiles différences dans la manière de gérer les transactions. Bref un client Linux / Mac OS qui enverrait des données pourries à Samba peut provoquer dans certains cas une déstabilisation majeure du serveur distant.
Dans les innombrables paramètres de Samba, vérifier s’il n’y aurait pas certains pour “limiter ce phénomène” Un client, même s’il envoie des données pourries ne devraient pas provoquer la déstabilisation du serveur distant. Le transfert doit s’interrompre et puis c’est tout. Encore une fois à partir d’un poste Windows il est assez rare de faire planter le serveur Samba de la BOX, le problème semble plutôt localisé sur des clients ‘non windows’
|
