10.11 El Capitan Perte de mes Disks

Lepitoux28

Membre enregistré
26 Avril 2017
5
0
47
Bonjour,



J’ai un gros problème.. je tourne avec 2 Disk en RAID 0

sur un boitier ICY BOX IB-RD3620SU3. Sans Aucune explication.. mon RAID n’apparait plus sur mon FINDER.

viewer.php
[/URL][/IMG]
koraid.jpg

je le vois encore dans mon Utilitaire de DISK… Je suis en panique la :(
Que doive faire ?

Par avance merci de votre aide.

Laurent
 
Salut Lepitoux

Ton boîtier attaché à ton Mac > va à : Applications > Utilitaires > lance le «Terminal». Dans la fenêtre ouverte > tu peux passer des commandes en mode texte > capables de retourner des informations (ou d'effectuer des opérations).

Saisis la commande (informative) :
Bloc de code:
diskutil ar list
et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande)

  • cette commande appelle l'utilitaire diskutil (disk_utility : utilitaire de disque - le même que pilote le logiciel graphique éponyme) > avec la spécification ar (apple_raid  en abrégé : raid logiciel Apple) > et le verbe list (lister les appareils) ;
  • en retour > tu vas voir s'afficher en tableau ce qui est identifié de ta Matrice RAID.

Sélectionne ce tableau > ⌘C pour copier dans le presse-papier > ce fil > Répondre > presse le bouton dans la petite barre de menus au-dessus du champ de saisie des messages > sous-menu </> Code > ⌘V pour coller le tableau dans la fenêtre de code (pour les retours du «Terminal» > c'est mieux ainsi plutôt que de poster une photo).

=> ces informations permettront de voir comment se présente la situation.
 
Merci Macomaniac.

J'ai tapé comme demandé : diskutil ar list
Cela n'a pas fonctionné alors j'ai tapé : diskutil list
Voici le resultat

Last login: Wed Apr 26 00:10:39 on console

MacBook-Pro-de-Laurent:~ Laurent$ diskutil ar list
No AppleRAID sets found

MacBook-Pro-de-Laurent:~ Laurent$ diskutil list

/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.3 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_CoreStorage Macintosh HD 499.4 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3

/dev/disk1 (internal, virtual):
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS Macintosh HD +499.0 GB disk1
Logical Volume on disk0s2
C4764643-AF70-4AB5-B5B6-D54FE7E71BCF
Unencrypted

/dev/disk2 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *6.0 TB disk2
1: EFI EFI 209.7 MB disk2s1
2: Apple_HFS 6.0 TB disk2s2

 
No AppleRAID sets found

C'est parce que le boîtier doit assurer un RAID matériel et pas logiciel.

Je présume alors que le disk2 listé par diskutil doit être un disque RAID Miroir virtuel de 6 To résultant de l'association de 2 disques de 3 To chacun.

Si ma conjecture est correcte > ce disque virtuel porte une table de partition GUID > la partition principale de 6 To étant gérée par un système de fichiers jhfs+ standard.

Dans ton cas de figure > aucun volume ne paraît défini par ce système de fichiers.

Tente les commandes (l'une après l'autre) :
Bloc de code:
diskutil repairDisk disk2
diskutil repairVolume disk2s2
diskutil info disk2s2

et poste ici les affichages retournés.
 
Oui c'est un boitier qui gere le Raid. Actuellement configuer en RAID 0

J'ai un doute... regarde se qu'il me propose (erase)

MacBook-Pro-de-Laurent:~ Laurent$ diskutil repairdisk disk2
Repairing the partition map might erase disk2s1, proceed? (y/N)

Il faut effacer mon disk la ?
 
Non : c'est un message courant d'avertissement sur une simple éventualité (« might » = "pourrait") > tu peux passer outre en tapant :
Bloc de code:
y
et en re-validant.

De toute façon > au point où tu en es (plus de volume monté) > tu n'as guère le choix.
 
MacBook-Pro-de-Laurent:~ Laurent$ diskutil repairdisk disk2
Repairing the partition map might erase disk2s1, proceed? (y/N) y
Started partition map repair on disk2
Checking prerequisites
Checking the partition list
Adjusting partition map to fit whole disk as required
Checking for an EFI system partition
Checking the EFI system partition's size
Checking the EFI system partition's file system
Checking the EFI system partition's folder content
Checking all HFS data partition loader spaces
Checking booter partitions
Reviewing boot support loaders
Checking Core Storage Physical Volume partitions
Updating Windows boot.ini files as required
The partition map appears to be OK
Finished partition map repair on disk2

MacBook-Pro-de-Laurent:~ Laurent$ diskutil repairVolume disk2s2
Started file system repair on disk2s2
Repairing file system
Checking Journaled HFS Plus volume
Checking extents overflow file
Checking catalog file
Invalid record count
The volume Raid could not be verified completely
File system check exit code is 8
Updating boot support partitions for the volume as required
Error: -69845: File system verify or repair failed
Underlying error: 8: POSIX reports: Exec format error

MacBook-Pro-de-Laurent:~ Laurent$ diskutil info disk2s2
Device Identifier: disk2s2
Device Node: /dev/disk2s2
Whole: No
Part of Whole: disk2
Device / Media Name: Raid
Volume Name:
Mounted: No
File System Personality: HFS+
Type (Bundle): hfs
Name (User Visible): Mac OS Extended
Journal: Unknown (not mounted)
Owners: Disabled
Partition Type: Apple_HFS
OS Can Be Installed: No
Media Type: Generic
Protocol: USB
SMART Status: Not Supported
Disk / Partition UUID: 7F5A957A-21E7-40A7-AA85-133951EF66BA
Total Size: 6.0 TB (6000731971584 Bytes) (exactly 11720179632 512-Byte-Units)
Volume Free Space: 0 B (0 Bytes) (exactly 0 512-Byte-Units)
Device Block Size: 512 Bytes
Read-Only Media: No
Read-Only Volume: Not applicable (not mounted)
Device Location: External
Removable Media: No
 
Bilan des commandes :

  • la table de partition GUID du disque virtuel disk2 de 6 To est valide ;
  • le système de fichiers de la partition disk2s2 est invalide -->
    • la raison en est un « invalid record count » à la vérification du fichier du catalogue B-tree - ce qui doit pouvoir se traduire par un décompte des données erroné.

Le fichier du catalogue est un dispositif logique en arborescence qui part d'une racine > et va jusqu'à des feuilles terminales (ou données) > par une série d'embranchements (appelés nœuds) > indexés par des valeurs numériques (ou clés). Il permet la recherche et l'accès aux fichiers > pour lecture > ajout > édition > suppression. Des erreurs dans le fichier du catalogue prennent vite un tour critique.

En effet > c'est le kernel de l'OS démarré («El Capitan» chez toi) > qui opère la probation des systèmes de fichiers des autres partitions de disques > et en cas de validation > opère le montage des volumes sur ces partitions. Lorsqu'un système de fichiers retourne des erreurs graves à la probation > le kernel rejette le montage du volume correspondant. C'est ton cas.

----------

Ce que je suis en train de me demander > c'est si les erreurs trouvées dans le système de fichiers de la partition disk2s2 sont bien « internes » au système de fichiers (= erreurs logiques) ; ou bien s'il pourrait y avoir un problème de lecture du système de fichiers induit par un facteur « externe » (= problème matériel).

Tu peux essayer de manipuler ton boîtier --> le détacher du Mac > le réattacher --> avec re-démarrages intercalaires > pour vérifier si le volume est ou non remonté (regarder si son nom réapparaît dans l'«Utilitaire de Disque».

Si ce genre de manipulation ne suscite pas de remontage du volume > il resterait à supposer que les erreurs sont bien internes au système de fichiers (je n'ai aucune idée dans ce cas de figure de la raison de leur survenue).

----------

La question devient alors : y a-t-il sur la partition disk2s2 (où ne monte plus de volume) des données auxquelles tu tiens ? Car s'il n'y avait pas de données à récupérer > un reformatage de la partition recréant un nouveau système de fichiers montant un volume vide réglerait la question.

Mais je me doute que tu as des données écrites que tu souhaiterais récupérer. Dans ce cas de figure > je ne peux que te suggérer 2 démarches (hélas payantes) -->

  • utiliser «DiskWarrior» pour tenter de lui faire restaurer un catalogue valide > de manière à remonter un volume dans lequel les données redeviendraient accessibles ;
  • utiliser un logiciel de récupération de données (genre «Data Rescue 4» ou «Stellar Mac Data Recovery») pour scanner les blocs de la partition et retrouver des fichiers.
 
Merci pour ton retour. Je viens de télécharger une version gratuite de EASEUS DATA RECOVERY
Il me retrouve la structure de mon DISK.... je vais donc tenter la recupération.

Maintenant ma question es de savoir se qu'il c'est passé ? Une erreur sur un disk ? Y a moyen d'analyser ?
Ou je dois me faire une raison et je ne connaitré jamais la raison de se plantage ?

J'avous etre perdu... je fait beaucoup de montage Video. Je stock sur mon RAID5 pour justement me permettre de faire une montage sans transferer sur le petit disk dur du MacBook Pro... mais visiblement cela semble bancale... et tres risqué
 
ma question es de savoir se qu'il c'est passé ? Une erreur sur un disk ? Y a moyen d'analyser ?
Ou je dois me faire une raison et je ne connaitré jamais la raison de se plantage ?

Dans ton cas > je n'ai que des spéculations hasardeuses à te proposer.

Tu dois avoir un RAID 0 (2 disques de 3 To chacun associés en mode miroir) > plutôt qu'un RAID 5 comme évoqué dans ton dernier message (3 disques minimum associés en mode redondance). Quoi qu'il en soit > je n'ai pas l'impression qu'il s'agisse d'une défaillance d'un de tes disques > non plus que du RAID.

Car la capacité du disque virtuel de 6 Go est bien identifiée. La table de partition GUID est sans erreur. C'est le système de fichiers (filesystem) affecté à la partition principale (disk2s2) qui est corrompu. Un type d'accident logique qui survient aussi bien avec des disques uniques (HDD ou SSD).

Un système de fichiers se compose d'une série de fichiers (comme un fichier du catalogue B-tree > un fichier des attributs étendus > un fichiers des segments en excès...) inscrits sur les premiers blocs logiques d'une partition. Cette structure, d'un type logique spécifique (jhfs+ = Apple_étendu journalisé chez toi), confère au reste de l'espace de la partition la forme d'un volume : un ensemble de présentation d'objets qui sont des fichiers. Lorsque le système de fichiers est "activé" > le volume est monté sur les blocs de la partition > lorsque le système de fichiers est "désactivé" > le volume est démonté. C'est le kernel de l'OS démarré > après probation du système de fichiers d'une partition > qui détermine son activation en l'absence d'erreurs graves > et par là le montage du volume sur la partition ; ou rejette son activation en cas d'erreurs graves > et par là laisse le volume démonté.

Ce bref aperçu brossé > la question que tu as posée équivaut à s'interroger sur la provenance des erreurs dans un système de fichiers (qui est donc la condition déterminante d'un volume utilisable sur un disque). Pfuitt ! Je souffre ici de mon absence (radicale) de culture informatique > qui me force à de simples spéculations.

J'ai comme l'impression que le simple usage récurrent d'un volume (lecture > édition > adjonction > suppression de fichiers) induit de petites erreurs dans le système de fichiers qui gère en continu les données de ce volume. Petites erreurs qui pourraient bien se composer en erreurs graves à la longue (genre : erreurs de catalogue). On parle beaucoup de « maintenance » et des logiciels variés se proposent pour en effectuer des tâches. Mais quand on regarde ce que font ces logiciels > cela peut se résumer à purger des fichiers (genre : caches). Interventions intérieures à un volume (celui de l'OS) > qui présupposent que le système de fichiers gestionnaire du volume assume bien ses fonctions. Il serait beaucoup plus judicieux de considérer que la maintenance critique est celle d'un système de fichiers (càd. de la condition du montage d'un volume) > dont il faudrait régulièrement corriger les petites erreurs induites par l'usage (avant que cela ne dégénère...).

La saturation de l'espace disponible d'un volume par des fichiers est aussi un facteur critique : le système de fichiers se verrouille littéralement et ne monte plus le volume qu'en lecture seule > ou pire encore des fichiers décisifs comme celui du catalogue ou celui de l'allocation des blocs se corrompent et le volume devient inmontable.

Mais il arrive aussi que des erreurs graves affectent tel ou tel fichier d'un système de fichiers à la suite d'un incident abrupt : plantage d'une mise à jour logicielle (d'OS par exemple) > extinction forcée du Mac > débranchage à l'arrache d'un périphérique > panne d'alimentation par secteur... Je ne saurais expliquer le mécanisme exact de ces répercussions d'un incident physique ou logique sur le système de fichiers gérant un volume monté. On peut s'efforcer d'éviter les manœuvres à risques (extinctions brutales / déconnexions d'appareils sans démontage préalable des volumes) > mais rien ne met à l'abri d'un accident logiciel ou d'alimentation.

Je ne peux pas dire quel facteur dans ton cas a planté le système de fichiers du volume de ton RAID. Quand tu auras récupéré (je l'espère) les données de ta partition > je ne peux que t'inviter à avoir une sauvegarde de ton volume RAID (ce qui impliquerait un second périphérique) > par ailleurs agir avec bon sens (pas de manœuvres à risques : démonter formellement les volumes > éviter les extinctions abruptes) > enfin vérifier / réparer régulièrement via l'«Utilitaire de Disque» le système de fichiers du volume RAID.