Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

Bonjour, je confirme avoir le même problème de changement de nom du disque dur (j'ai un disque dur USB), cela rend inopérent par exemple ma sauvegarde home assistant car il se base sur le nom de réseau du disque dur.
Le disque s'appelle "disk 1" et quand le problème apparaît, le disque s'appelle "disk 1 1"
Les seuls moyens de résoudre le problème :
- débrancher et rebrancher le disque dur via la prise USB
- redémarrer la box

Toujours présent en 4.9.11.1

j'ai fait un chkdsk sur mes disques :
C:\Users\Alexandre>chkdsk H: /f
Le type du système de fichiers est exFAT.
Le numéro de série du volume est B9B3-EA33
Windows vérifie les fichiers et les dossiers… Le nom de volume est Freebox_HDD.
L’examen de la bitmap du volume a révélé une défaillance.
Vérification des fichiers et des dossiers terminée.

Windows a effectué des corrections sur le système de fichiers.
Aucune autre action n’est requise.

976744960 Ko d’espace disque au total.
802737920 Ko dans 280 fichiers.

   11264 Ko dans 44 index.
       0 Ko dans des secteurs défectueux.
     768 Ko utilisés par le système.

173995008 Ko disponibles sur le disque.

  262144 octets dans chaque unité d’allocation.
 3815410 unités d’allocation au total sur le disque.
  679668 unités d’allocation disponibles sur le disque.

C:\Users\Alexandre>

Bonjour

Ce qu'il se passe c'est qu'il se produit un 'reset' du contrôleur USB lors de forte charge.

Ce reset créé une coupure 'sale', à savoir le device mappé en Freebox_HDD par le kernel de la freebox n'a pas été supprimé de la table de mappage et existe toujours dans /dev mais est inaccessible.

Quand le contrôleur est à nouveau opérationnel après son 'reset', le kernel créé un nouveau périphérique (/dev/sdb) et la box créé un nouveau mappage Freebox_HDD1 pour le nouveau périphérique

Pourquoi ?
Parce que tout se passe très vite (souvent en moins d'1 seconde), le kernel n'a pas le temps de supprimer l'ancien device /dev/sda suite au reset

C'est un comportement normal du noyau Linux.

Ce qui est anormal c'est que le contrôleur 'reset' à forte charge, mais ça c'est probablement un souci hardware ou une interférence qui déstabilise le chipset (nécessite souvent dans ce cas de redessiner les pistes sur le PCB), ou un problème de quantité de courant électrique qui n'est pas suffisante à forte charge.

Il est d'ailleurs recommandé d'utiliser des disques USB ayant une alimentation électrique séparée et indépendante de de l'USB-PD (USB Power Delivery) de la Freebox

Cordialement
nbanba

Bonjour nbanda

Merci de ta réponse. Le problème est que ce bug intervient autant sur le disque dur en USB (2,5" 1 To USB 3) que sur le NVMe qui est dans la Ultra. Je n’ai plus rencontré le bug de changement de nom depuis mi-septembre environ ; je croise les doigts pour que ça dure.

En revanche, le bug gênant reste celui du stockage libre. Ayant un disque NVMe de 500 Go et un disque externe de 1 To, ils se remplissent très vite avec des photos et vidéos de vacances en 4K Blu-ray Remux. Je suis donc obligé de faire une opération de nettoyage une fois par mois.

En version 4.9.14, le problème de suppression des fichiers est étrangement résolu : j’ai enfin retrouvé la taille des fichiers supprimés. Je ne sais pas quels changements Free a apportés, mais tant mieux !

Bonjour

@Algi dans votre commentaire:
https://dev.freebox.fr/bugs/task/40474#comment191315

vous dites rencontrer le même souci avec les NVMe.
Ça ressemble à un souci électrique global…

Par contre vous avez de la chance que le NVMe revienne tout seul (avec un autre id) car c'est du PCI Express et la plupart des controlers PCIE pour matériel embarqué ne sont pas capable de faire du hotplug après un reset et provoquent l'erreur:

journalctl -k -b-43 | egrep '0000:07:00.0' 
 pci 0000:07:00.0: [15b7:5015] type 00 class 0x010802 PCIe Endpoint
 pci 0000:07:00.0: BAR 0 [mem 0x00000000-0x00003fff 64bit]
 pci 0000:07:00.0: Max Payload Size set to 256 (was 128, max 512)
 pci 0000:07:00.0: 31.504 Gb/s available PCIe bandwidth, limited by 8.0 GT/s PCIe x4 link at 0000:03:0b.0 (capable of 63.012 Gb/s with 16.0 GT/s PCIe x4 link)
 pci 0000:07:00.0: BAR 0 [mem size 0x00004000 64bit]: can't assign; no space
 pci 0000:07:00.0: BAR 0 [mem size 0x00004000 64bit]: failed to assign

BAR : Base Address Register soit le registre PCI Express ou le périphérique dit au système :
"Hello c'est ici que se trouve ma mémoire ou mes capacités d'entrées/sorties"
soit l'endroit ou le périphérique expose son registre MMIO (Memory-Mapped I/O) ou ses capacités d'entrées / sorties (I/O)

Donc aussi gênant ça puisse être, vous avez de la chance que le disque NVMe remonte tout seul après failure ou reset du controller et sans être obligé de reboot la box (pour que le système re-expose le bus PCIE, renegocie les 'lanes' bifurquées et les 'lanes speed'au controller du CPU)

Concernant le souci évoqué dans votre dernier poste:
https://dev.freebox.fr/bugs/task/40474#comment191450
ça donne plutôt l'impression que le disque est défaillant

Cordialement
nbanba

@nbanda,
Pour info, le problème avec le NVMe n’est survenu qu’une seule fois depuis juin/juillet, tandis que pour le HDD, cela s’est produit environ 4 ou 5 fois.
Un détail important que j’ai oublié de mentionner : au départ, mes deux disques étaient formatés en ext4 directement depuis la Freebox. Quand j’exécutais la "vérification du disque" depuis FreeboxOS, celle-ci échouait systématiquement et éjectait le disque (que ce soit le HDD ou le NVMe), rendant impossible toute reconnexion, aussi bien logicielle que physique.Seul solution le redémarrage de la box.
Depuis, j’ai reformaté les disques en exFAT, et l’option de vérification est désormais grisée.
Ce qui m’a le plus posé problème, et qui était le plus fréquent, c’était la non-restauration de l’espace libéré après suppression de fichiers, aussi bien sur le NVMe que sur le HDD. Les deux disques affichaient également des erreurs sous Windows. J’ai testé avec plusieurs HDD, pensant initialement que mon disque externe était défaillant, mais le second a présenté les mêmes symptômes. Le NVMe, lui, est relativement neuf (environ 100 jours d’utilisation, 15 To écrits et 24 To lus).
Depuis la mise à jour 4.9.14, ce bug semble résolu — du moins, je l’espère.