10.14 Mojave Pegasus R4 aprés cht des disques impossible de supprimer la partition pour augmenter la capacité

[Cli69]

Bonjour
J'ai le plaisir d'avoir un pegasus R4 (V1) dont j'avais déjà augmenté la capacité de (4x1To à 4x3To).
Je viens d'installer 4 disques de 6 To et la création du disque logique aprés 4 reconstructions est bien en place.
Le souci apparait via l'utilitaire de disque.
Le disque apparait ainsi à 9to (ancienne configuration)
puis en sélectionnant le partitionnage, on a ceci:




En supprimant l'espace grisé et en confirmant sa suppression, l'opération échoue presque instantanément avec ce message :


En passant par le terminal j'ai les informations suivantes :

╰─$ diskutil list                       
/dev/disk0 (internal):
...
/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *18.0 TB    disk3
   1:                        EFI EFI                     209.7 MB   disk3s1
   2:                 Apple_APFS Container disk4         9.0 TB     disk3s2

/dev/disk4 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +9.0 TB     disk4
                                 Physical Store disk3s2
   1:                APFS Volume VIDEO PHP RAID          8.7 TB     disk4s1

Le détail pour disk3s2 donne

╰─$ diskutil info disk3s2
   Device Identifier:         disk3s2
   Device Node:               /dev/disk3s2
   Whole:                     No
   Part of Whole:             disk3

   Volume Name:               Not applicable (no file system)
   Mounted:                   Not applicable (no file system)
   File System:               None

   Partition Type:            Apple_APFS
   OS Can Be Installed:       No
   Media Type:                Generic
   Protocol:                  SAS
   SMART Status:              Not Supported
   Disk / Partition UUID:     A1081A88-06DB-46C3-B60B-7F8E2CB45138
   Partition Offset:          209735680 Bytes (409640 512-Byte-Device-Blocks)

   Disk Size:                 9.0 TB (8999788830720 Bytes) (exactly 17577712560 512-Byte-Units)
   Device Block Size:         512 Bytes

   Read-Only Media:           No
   Read-Only Volume:          Not applicable (no file system)

   Device Location:           External
   Removable Media:           Fixed

   Hardware AES Support:      No

Pour disk4s1

Device Identifier:         disk4s1
   Device Node:               /dev/disk4s1
   Whole:                     No
   Part of Whole:             disk4

   Volume Name:               VIDEO PHP RAID
   Mounted:                   Yes
   Mount Point:               /Volumes/VIDEO PHP RAID

   Partition Type:            41504653-0000-11AA-AA11-00306543ECAC
   File System Personality:   APFS
   Type (Bundle):             apfs
   Name (User Visible):       APFS
   Owners:                    Disabled

   OS Can Be Installed:       Yes
   Media Type:                Generic
   Protocol:                  SAS
   SMART Status:              Not Supported
   Volume UUID:               92A01835-6028-34FC-B73E-341B6F64182A
   Disk / Partition UUID:     92A01835-6028-34FC-B73E-341B6F64182A

   Disk Size:                 9.0 TB (8999788822528 Bytes) (exactly 17577712544 512-Byte-Units)
   Device Block Size:         4096 Bytes

   Volume Total Space:        9.0 TB (8999788822528 Bytes) (exactly 17577712544 512-Byte-Units)
   Volume Used Space:         8.7 TB (8688452894720 Bytes) (exactly 16969634560 512-Byte-Units) (96.5%)
   Volume Free Space:         311.3 GB (311335927808 Bytes) (exactly 608077984 512-Byte-Units) (3.5%)
   Allocation Block Size:     16384 Bytes

   Read-Only Media:           No
   Read-Only Volume:          No

   Device Location:           External
   Removable Media:           Fixed

   Hardware AES Support:      No

J'ai essayé les commandes de redimensionnement en manuel

╰─$ diskutil coreStorage resizeStack 92A01835-6028-34FC-B73E-341B6F64182A 0b
92A01835-6028-34FC-B73E-341B6F64182A does not appear to be a valid Core Storage Logical Volume UUID or disk

et

$ diskutil coreStorage resizeStack A1081A88-06DB-46C3-B60B-7F8E2CB45138 0b
A1081A88-06DB-46C3-B60B-7F8E2CB45138 does not appear to be a valid Core Storage Logical Volume UUID or disk

J'aimerais éviter de reformater l'ensemble en devant faire deux transferts de 9To et surtout ne pas perdre les données qui sont dessus lors du redimensionnement.

Il y a sans doute une logique que je n'ai pas bien intégrée. Si vous avez des pistes ...

 

[Membre supprimé 1060554]

Bonsoir Cli

Passe la commande :

sudo gpt show disk3

• à validation > une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe de session admin en aveugle - aucun caractère ne se montrant à la frappe - et revalide

• la commande affiche la distribution des blocs du disk3 (si cet index cible bien ton appareil)

Poste le tableau retourné.

Question : un Pegasus R4 --> est-ce que ce n'est pas un boîtier à 4 baies permettant d'associer 4 disques en mode : Raid matériel ? - si oui > quel est le type du Raid : entrelacé > miroir > concaténé ?

 

[Cli69]

Bonjour @macomaniac

Voici ce que retourne la commande

─$ sudo gpt show disk3                                                     1 ↵
       start        size  index  contents
           0  2197214070

Pour répondre à ta question le pegasus R4 est effectivement un boitier 4 baies que tu peux monter en différentes matrices RAID matériel. Le mien est en raid 5. Leur particularité est d'être en thunderbolt. Fiable et pro.
il y a eu un papier dans macg sur cette série.

 

[Membre supprimé 1060554]

C'est tout ce que tu as comme retour de commande ? -->

- je ne vois aucune description de partitions > rien qu'une indication de taille = 2197214070 blocs. La taille assignée au bloc (d'après un des autres tableaux que tu as postés) est de 4096 octets - soit une valeur octuple de la taille standard de 512 octets. 2197214070 blocs x 4096 = 8999788830720 octets = 9 To --> c'est donc la taille actuelle de ton Conteneur apfs.​

----------

Le Raid 5 (me semble-t-il) est un Raid qui combine la rapidité d'un Raid 0 (entrelacé au sens où il y a découpage des données en bandes et copie simultanée des bandes vers divers disques) et la sécurité d'un Raid 1 (miroir au sens où il y a écriture de bits de parité).

- avec un appareillage de 4 disques > l'espace d'un disque sur les 4 devrait être occupé par les bits de parité > l'espace disponible en fichiers accessibles étant donc de 3 sur 4. Si tu as mis 4 disques de 6 To = 24 To au total => 6 To devraient être occupés par les bits de parité (sauvegarde) et 18 To disponibles pour les fichiers. C'est ce qui paraît confirmé par ton Utilitaire de disque > qui trouve une taille totale de 18 To > dont 9 To seulement inclus dans le volume apfs VIDEO PHP RAID.​

----------

Passe la commande :

diskutil ap resizeContainer disk4 0b ; diskutil list

• qui dilate le Conteneur apfs à la totalité de l'espace libre disponible > puis réaffiche la configuration des disques

Poste l'ensemble de l'affichage retourné --> qu'on voie si quelque chose est sorti de cette commande.

 

[Cli69]

Tu as tout ce que renvoie la commande !
J'ai du mal à bien comprendre la situation.
J'essaie cela lundi.

 

[Membre supprimé 1060554]

J'ai du mal à bien comprendre la situation.

- on est deux alors à partager la même incompréhension (ce qui te permet de te sentir moins seul) :hilarious:​

 

[Cli69]

Le casse tête continu, mais reste cohérent.

La commande diskutil list donne

diskutil list                                                           1 ↵
/dev/disk0 (internal):
   #:                       TYPE NAME                    SIZE       IDENTIFIER

[...]

/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *18.0 TB    disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:                 Apple_APFS Container disk3         9.0 TB     disk2s2

/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +9.0 TB     disk3
                                 Physical Store disk2s2
   1:                APFS Volume VIDEO PHP RAID          8.7 TB     disk3s1

Du coup en essayant de dilater le conteneur APFS j'obtiens un message d'erreur proche de ce que me renvoie l'utilitaire de disque :

╰─$ diskutil ap resizeContainer disk3 0b
Started APFS operation
Error: -69743: The new size must be different than the existing size

 

[Membre supprimé 1060554]

Est-ce que tu as des données dans le volume VIDEO PHP RAID ou pas ?

 

[Cli69]

Oui, presque 9To
3 ans de taff

 

[Cli69]

J'essaie d'en savoir plus sur Error: -69743 ! Je risque d'être déçu

 

[Membre supprimé 1060554]

Donc on ne peut pas tenter de réinitailisation.

Passe la commande (informative) :

diskutil ar list

• qui affiche toute matrice RAID trouvée (si elle est de type logique et pas matériel)

=> est-ce que tu obtiens un retour ?

 

[Cli69]

╰─$ diskutil ar list                                                                                       1 ↵
No AppleRAID sets found

 

[Cli69]

C'est du RAID matériel, le disque est vu comme un seul disque.
Via l'utilitaire promise il s’affiche ainsi :

 

[Membre supprimé 1060554]

Pas de RAID logique - mais un RAID matériel, donc -->

- le type que tu as choisi (RAID 5) a l'air de consommer > sur 24 Go d'espace-disque total > 6 To en bits de parité (sauvegarde) > en exportant comme espace logique : 18 To.​

- je ne comprends pas pourquoi les 18 To d'espace logique ne sont pas disponibles > mais seulement 9 To (1/2). Tout se passe comme si un RAID 1 (= miroir) > où la sauvegarde est égale à l'espace disponible du volume --> se trouvait superposé. À moins que le format apfs choisi pour le volume exporté --> n'occasionne cette perte énorme d'espace disponible.​

=> il faudrait pouvoir manipuler l'espace logique (reformatage) pour voir si on peut récupérer les 18 To avec un autre format de volume. Mais comme tu as des données ce n'est pas possible.

 

[Cli69]

J'ai passé une partie de la matinée avec le support d'Apple.
Ils ont bien constaté que le disque logique était de 18To




Dedans il y a un conteneur APFS de 9To


Dans lequel il y a une partition de 9To



Il n'était pas sûr qu'on puisse augmenter la taille de conteneur disk5 qui bloque ce qui est en dessous.
C'est monté jusqu'au superviseur qui a regardé pleins de trucs. Et qui a conclu en disant d'aller voir le fabriquant du Pegasus , qui ne le maintient plus ...

 

[Cli69]

Dernière option, reformatage complet dés que j'aurai transférer les 9To de données vers un autre RAID ...
J'espère qu'il n'y a pas de bridage du pegasus R4 (modèle 1) à 9To ! Je n'ai rien trouver en ce sens.
A suivre

 

[Membre supprimé 1060554]

Bon courage pour la recopie de 9 To de données ! ...

- tenter ensuite un reformatage dans un format non apfs (= jhfs+) --> permettra de voir si tu récupères les 18 To disponibles.​

- voire tenter d'autres types de RAID (matériel) - ceux qui sont disponibles avec le boîtier.​

 

[Cli69]

Finalement j'ai du reformater. Et là, pas de soucis, 18To sur un Pegasus R4 Modèle 1, cela passe sans soucis !! (C'est parti pour 48h de rétro transfert ... )

 

[Membre supprimé 1060554]

Content pour toi !

- je vois que tu as reformaté en jhfs+. C'est peut-être le format apfs qui ne passait pas ?​

 

[Cli69]

Il était en HFS+ j'ai fait la bêtise de le transformer en apfs.