In che modo OSX assegna i numeri di disco?

I numeri di unità sono assegnati dal sistema operativo in base al principio "primo arrivato, primo servito". Lo schema di numerazione è il seguente (con una N maiuscola è un numero):

diskN - fa sempre riferimento a un'unità primaria (ovvero l'intera unità)

diskNs1 - sempre EFI

diskNs2 - Primo volume effettivo sull'unità

diskNs3 - Secondo volume sull'unità, se ce n'è uno ... può andare avanti per tutti i volumi che hai.

È possibile ottenere alcune informazioni su unità e volumi con la versione GUI di diskutil aprendo diskutil, facendo clic sull'unità o sul volume, quindi facendo clic con il pulsante destro del mouse sull'elemento e selezionando "Informazioni" dalla finestra di dialogo.

Un altro modo è aprire una finestra di terminale e digitare "diskutil list" e ti fornirà un elenco di tutte le unità, le loro dimensioni e nomi delle partizioni (non digitarlo con le virgolette, però). Se desideri informazioni specifiche su un disco o tipo di volume "diskutil info", ad esempio:

diskutil info disk0 OR diskutil info disk0s3

L'utility fornirà informazioni dettagliate su ciascuna. Personalmente trovo che usare Terminal.app sia un po 'più semplice perché posso reindirizzare l'output a un file se è necessario invece di tagliare e incollare e mostra le relazioni dei volumi con le partizioni un po' più chiaramente (IMHO).

Non penserei che scambiare le unità intorno alle baie farebbe alcuna differenza. Nei miei sistemi di sviluppo posso passare alle unità firewire, prenderne una offline, portare l'altra offline, eseguire il primo backup e anche se ottengono ID di unità diversi, se ne viene impostato uno come avviabile rimarrà avviabile. I Mac utilizzano gli UUID per etichettare le unità che rimangono uniche per l'unità, indipendentemente dall'assegnazione del disco.

Il firmware per un Mac Pro potrebbe consentire a un utente di predisporre alloggiamenti specifici per essere avviabili.

Lo penserei. Lavoro molto sugli hard disk su sistemi Mac, e per quanto riguarda almeno le unità esterne, l'ordine in cui arrivano non sembra mai avere importanza in base a dove sono collegati in cascata nel sistema. Nel mondo delle unità rimovibili, penso che l'UUID sia il numero più importante. Non vedrei ragioni logiche per cui OS X avrebbe tentato di applicare qualcosa di diverso per le unità interne. Tieni presente che all'avvio si verificano molti eventi casuali, come il monitoraggio della temperatura e la regolazione del sistema, che possono interferire con il tempo in cui ogni unità viene sondata e assegnare un'identità.

Penso che per la maggior parte, almeno in condizioni generalmente medi, una sequenza di avvio sarebbe almeno in qualche modo ripetibile, ma ho anche visto periodicamente il cambio dell'ID dell'unità ... eppure continuano ad avviarsi nel ordine corretto. Se Apple fosse intelligente, e penso che lo sia, ha come target l'UUID, non una designazione di unità come / dev / rdisk0s3. In questo giorno ed età, in particolare con i sistemi che possono essere configurati per l'avvio di un'unità esterna per impostazione predefinita anche se è presente un'unità interna, deve essere l'UUID che indica al sistema da cui eseguire l'avvio.

Se hai mai avuto un sistema che è stato predefinito per avviare un'unità esterna e quindi rimuoverlo, il sistema operativo in genere, al momento dell'avvio, lampeggia un punto interrogativo e quindi "caccia" per un altro disco rigido. Se ne trova uno, si avvia, in caso contrario, si ottiene un punto interrogativo lampeggiante O il segno proibito.

Un'ottima fonte di informazioni, anche se probabilmente troppo tecnica per la maggior parte degli utenti del sistema, è il libro di SCSC sulla risoluzione dei problemi del disco rigido. Puoi andare su questo sito, andare alla sezione download e ottenere il libro "Risoluzione dei problemi del disco rigido" (nome accattivante, eh?):

link

Il loro libro descrive un sintomo che si verifica su molti computer (eventualmente) chiamati "errori generici". Un guasto generico non è un guasto di un componente elettronico, è in realtà un guasto meccanico, come tracce screpolate in schede logiche, collegamenti via cavo intermittenti, ecc. L'intermittenza di un tale problema può ritardare e eventualmente impedire il riconoscimento di unità nella loro "normale" "ordine.

Anche se SCSC dà a Scannerz il loro prodotto come sostanzialmente utilizzabile da chiunque, penso che il prodotto sia probabilmente più adatto a tecnici e ingegneri, o almeno a qualcuno che abbia una certa conoscenza dell'hardware. Nella sezione avanzata di risoluzione dei problemi del loro libro, parlano di sostituire i componenti nello stesso modo in cui cambio la mia maglietta ... la maggior parte delle persone sa come cambiare le camicie, ma non molti sanno come scambiare cavalieramente un disco rigido, in particolare su un laptop .

La ragione per cui dico tutto questo è che se i tuoi ID di unità stanno misteriosamente cambiando le loro identità, potresti avere quello che descrivono come un "difetto generico intermittente" nel loro libro, che è comunque gratuito. Vale la pena dare un'occhiata, comunque.

Spero che questo aiuti qualcuno.

Penso che le risposte siano eccessivamente semplicistiche nelle loro ipotesi (e quindi traggano conclusioni che sono eccessivamente generalizzate).

Non rispondono in modo specifico alla domanda su come il sottosistema bsd (aggiunto al microkernel Mach XNU ibrido) si rapporta effettivamente al boot-loader & a turno la procedura di inizializzazione del firmware sotto quella.

(Il fatto che IOkit offra il rebinding dinamico dei dispositivi e degli spazi dei nomi è -yes, ovviamente!) una struttura felice che sottende plug'n'play - ma questo risultato è un punto separato da come l'assegnazione del drive osx il protocollo funziona effettivamente).

In effetti esiste almeno un caso molto pratico in cui il nome del dispositivo bsd - ereditato dall'albero del dispositivo del firmware (?) - ha una conseguenza molto pratica: EG alcuni programmi sono configurati per l'installazione su / work con l'unità di avvio che è (in qualche modo) canonically defined / hard-wired per essere solo il primo volume interno enumerato all'avvio !? :( ...

... ma se l'utente ha la necessità di designare un altro volume (esterno) come unità canonica0 (un requisito -aka restriction! - per alcuni tipi di software di backup online (ehm, Carbonite viene in mente hehe ad esempio) avendo quindi una precisa comprensione di come Darwin assegna i numeri di guida all'improvviso diventa di vitale importanza!

Quindi: se qualcuno sa come è possibile costringere un altro volume ad essere 'benedetto' come bsd0 (che è distinto dalla cartella di sistema di quel volume che viene contrassegnato come un dispositivo avviabile), la tua comprensione sarà molto apprezzata :)