Da HFS+ a APFS

Da anni ho due dischi esterni sempre collegati al mio Mac Mini M1 di casa.¹ Il primo è un SSD esterno da 2 TB che contiene tutti i documenti di lavoro e personali, il codice degli script e delle applicazioni che sviluppo, la documentazione e così via.

Un secondo disco, questa volta meccanico, conserva invece tutte le foto e la musica, e anche una grande libreria di software soprattutto per macOS e Linux, che ho cominciato ad archiviare più di vent’anni fa, quando non si trovava tutto in rete, e che continuo ad aggiornare ancora oggi.

Questa configurazione è necessaria, perché il disco interno da 1 TB è troppo piccolo per le mie esigenze. Ma si rivela anche molto utile ogni volta che passo ad un nuovo Mac: una volta configurato macOS e installate le applicazioni indispensabili, mi basta collegare i due dischi esterni per avere a disposizione tutto ciò che mi serve per lavorare.

– Fonte: William Warby su Unsplash.

Dal punto di vista velocistico non noto grosse differenze tra il disco interno e l’SSD esterno, anche perché per le cose che faccio io (principalmente scrivere e sviluppare software) il collo di bottiglia non è certo la velocità di lettura o scrittura del disco. Anche i file multimediali sul disco meccanico non sono un grosso problema, quando uso Foto e Musica posso anche permettermi di perdere qualche secondo di troppo.

Fino a macOS Monterey la visualizzazione del contenuto dei dischi esterni è sempre stata praticamente istantanea, anche quando avevo a che fare con cartelle contenenti migliaia e migliaia di file.

Con Sonoma, improvvisamente, è cambiato tutto. Ogni volta che aprivo una cartella contenente un gran numero di file o di altre cartelle, mi toccava aspettare diverse decine di secondi prima di riuscire a vederne il contenuto. Sequoia ha migliorato un po’ le cose, ma solo temporaneamente, perché nelle ultime release la velocità di apertura delle cartelle dei dischi esterni è tornata ad essere esasperante.

Non è un problema hardware, lo stesso disco collegato ad un Mac con Monterey mostra i file in modo praticamente istantaneo. Il problema quindi è di natura software, o meglio è legato a come macOS gestisce i due filesystem principali del mondo Mac, HFs+ e APFS.

APFS

Nel 2017, dopo quasi vent’anni di HFS+, Apple ha introdotto un nuovo filesystem ottimizzato per i dispositivi di memoria a stato solido, denominato con poca originalità Apple File System (APFS).

Fino a Monterey i due filesystem hanno convissuto pacificamente: APFS era diventato obbligatorio per il disco di sistema (per capirci, quello da cui si avvia il Mac e che contiene il sistema operativo e le applicazioni), ma niente impediva di continuare ad usare HFS+ per i dischi esterni, che in questo modo rimanevano leggibili anche dai Mac più datati e, con qualche difficoltà, anche da Linux e Windows.

A partire da Sonoma (forse anche da Ventura, che ho sempre evitato di usare) l’accesso al contenuto delle cartelle dei dischi HFS+ è diventata lentissimo. Non credo che Apple l’abbia fatto intenzionalmente, magari per forzare gli utenti ad usare APFS. È più probabile che sia stato un banale bug, mai corretto perché Apple non ha nessun interesse a continuare a supportare HFS+. Il rallentamento, infatti, riguarda solo la visualizzazione di file nel Finder, mentre la loro apertura o salvataggio non veniva penalizzato in alcun modo.²

Per pigrizia, ho convissuto per due anni con questi rallentamenti. Nel frattempo ho sostituito il disco esterno meccanico da 2 TB con un SSD NVMe;³ la velocità di apertura delle cartelle è migliorata, ma molto meno di quanto sarebbe stato logico aspettarsi.

E allora qualche giorno fa ho deciso di fare il grande salto e di convertire i due dischi esterni ad APFS.

Da HFS+ a APFS

Con Disk Utility, passare da HFS+ a APFS è facilissimo: basta cliccare con il tasto destro del mouse sul disco da modificare e selezionare Convert to APFS....

Prima di iniziare, è utile selezionare la voce Show All Devices del menu View (o cliccando sull’icona View della barra degli strumenti di Disk Utility), in modo da vedere come cambia la struttura del disco passando da HFS+ a APFS.

In teoria, il processo di conversione non danneggia i file presenti sul disco, ma meglio non fidarsi e fare sempre un backup prima, non si sa mai. Parlo per esperienza, come leggerete fra poco.

Con il primo disco, l’SSD da 2 TB, non ho avuto problemi, magari anche perché il disco era relativamente vuoto, avendo solo 500 GB occupati sui 2.000 totali. La conversione da HFS+ a APFS ha richiesto solo una manciata di secondi e dopo il disco è diventato finalmente veloce e reattivo, come è normale per un SSD.

Leggi pure ma non puoi scrivere

La conversione del disco meccanico è stata una faccenda completamente diversa. Questo disco, al contrario del precedente, ha solo 500 GB liberi su 2.000 totali. Ma 500 GB sono pur sempre un quarto della capacità totale e quindi, dopo la buona esperienza appena fatta, ho deciso di iniziare senza fare un backup, tanto i file contenuti potevano sempre essere ripristinati con Time Machine

Ma al momento di convertire il disco in APFS, Disk Utility si è messo a macinare per un bel po’, magari tutto è durato solo un minuto o due, ma un minuto può essere lunghissimo quando si fanno queste cose. E dopo Disk Utility si è bloccato, avvertendomi che il processo di conversione era fallito.

Per fortuna, nonostante l’errore il disco continuava a funzionare come al solito. E per questo non posso che ringraziare con calore gli sviluppatori Apple, che sono stati bravissimi a fare in modo che la conversione del filesystem, un processo estremamente delicato che va a modificare la struttura di fondo del disco, potesse fallire senza fare danni ai file contenuti sul disco.

Naturalmente ci ho riprovato, ma il risultato è stato identico.

A questo punto e prima di riprovare di nuovo, ho deciso che era più saggio fare prima un backup di tutto su un ennesimo disco esterno. C’è voluta una notte intera, ma meglio non rischiare troppo.

Sarà stata una premonizione, perché al terzo tentativo Disk Utility si è arreso riportando l’errore -69860, “The underlying task reported failure on exit” (L’operazione associata ha restituito un errore in uscita), che è così vago da non significare niente. La conseguenza però era che il disco era diventato read-only, potevo leggere tranquillamente tutti i file, ma non potevo più scriverci sopra nemmeno un bit.

Avendo a disposizione un backup appena fatto non mi sono scomposto più di tanto e, sempre con Disk Utility, ho cancellato tutto il disco, scegliendo questa volta di usare APFS come filesystem. Per farlo, basta selezionare il disco e poi cliccare sul tasto Erase della barra degli strumenti di Disk Utility.

Ripristinare i file

A questo punto si trattava di ripristinare i file dal backup. All’inizio ho provato ad usare il Finder, trascinando una alla volta le cartelle dal disco di backup a quello da ripristinare, appena riformattato in APFS .

Nessun problema con le cartelle contenti (relativamente) pochi file, ma con una molto più grossa il Finder a un certo punto si è arreso, affermando che il disco conteneva già un file con lo stesso nome. Ovviamente il file non c’era, perché stavo ricostruendo il disco da zero, ma non avevo la minima voglia di perdere altro tempo ad indagare, per poi magari ritrovarmi dopo un’ora con lo stesso errore.

E allora ho aperto il caro vecchio Terminale, mi sono spostato con cd nella cartella iniziale del disco da ripristinare (che qui chiamerò Media HD),

% cd "/Volumes/Media HD"

e ho copiato una alla volta le cartelle dal disco di backup (Backup HD) a quello di destinazione. Prima di fare tutto questo, ho riformattato Media HD in modo da ripartire da una configurazione pulita.

% cp -p -R "/Volumes/Backup HD/<directory A>" .
% cp -p -R "/Volumes/Backup HD/<directory B>" .
...

Nei comandi qui sopra, <directory A>, <directory B> (senza lo / finale) e così via indicano i nomi delle cartelle (o directory) da copiare. L’opzione -p specifica che la copia non deve modificare gli attributi dei file,⁴ mentre -R indica che devono essere copiati in modo ricorsivo tutti i file e le cartelle contenute nella cartella da ripristinare. Attenzione: il . alla fine di ogni comando è importante ed indica che i file verranno copiati nella cartella corrente del disco di destinazione.

Il bello di usare il Terminale è che, una volta che il processo di copia è iniziato, lo si può mettere da parte e fargli fare il suo lavoro mentre noi ci dedichiamo ad altro. Basta solo fare attenzione a non chiudere il Terminale e a non toccare il disco di backup e quello di destinazione.

Il brutto invece è che non abbiamo la più pallida idea di cosa stia succedendo e di quanti file siano stai già copiati. Usare l’opzione -v è fuori discussione, perché con questa cp stamperebbe sul terminale il nome e il percorso di ogni file copiato, rallentando enormemente tutta l’operazione.

Molto meglio aprire una seconda scheda del Terminale, spostarsi (se non compare già automaticamente) nella cartella iniziale del disco da ripristinare con

% cd "/Volumes/Media HD"

e poi eseguire il comando

% du -h -d 1 "/Volumes/Media\ HD/<directory A>"

che restituirà la lista delle cartelle contenute in <directory A> con la relativa dimensione, con alla fine la dimensione totale occupata da <directory A>. Confrontandola con la dimensione dalla cartella sul disco di backup è facile avere una idea di quanto manca alla fine della copia.

Una avvertenza: quando cp è impegnato a copiare un file di grandi dimensioni du può essere molto lento a rispondere. Abbiate pazienza e non preoccupatevi, questi sono strumenti Unix, roba affidabile che va in crash solo se li prendete a martellate.

Anche il Terminale può fare le bizze

Anche se il Terminale è quasi sempre più affidabile dell’interfaccia grafica, ci sono casi, rari per fortuna, in cui anche il Terminale può dare problemi.

A me è successo con una cartella di una decina di GB, contenente un numero enorme di file piccolissimi disposti in cartelle molto annidate, che è sempre stata difficile da trasferire da un disco all’altro. In genere, la cosa migliore da fare è comprimere la cartella dal solito Terminale,

% tar -czf cartella_grande_con_tanti_file.tar.gz "Volumes/Media HD/Cartella grande con tanti file"

trasferirla all’altro disco e poi espanderla con

% tar -xzf cartella_grande_con_tanti_file.tar.gz

L’ho fatto tante volte (purtroppo!) e ha sempre funzionato. Questa volta no: al momento di decomprimere il file è venuto fuori un “Special header too large error” (Errore: intestazione speciale troppo grande) che potrebbe essere legato a qualche modifica alla cartella o ai suoi file avvenuta quando cercavo di convertire il disco in APFS.

Il problema è che potevo avere tutti i backup del mondo, ma se non riuscivo a decomprimere il file avrei dovuto ripristinare la cartella da Time Machine, una cosa che avrebbe richiesto, ne sono sicuro, un numero spropositato di ore.

Per fortuna sul Mac ho sempre qualche utility che magari uso pochissimo, ma che quando serve si rivela fondamentale. È il caso di The Unarchiver di MacPaw, che si trova sull’App Store. Non chiedetemi come e perché, ma The Unarchiver è riuscito a decomprimere il file tar.gz senza fare una piega, e l’ha fatto pure molto velocemente, forse più velocemente del solito tar da Terminale.

Conclusioni

Alla fine tutta la storia si è risolta felicemente, e sono riuscito a convertire i miei due dischi esterni da HFS+ a APFS senza perdere nemmeno un dato e in meno tempo di quello che avrei pensato.

Ora l’accesso ai dischi è tornato ad essere fulmineo o quasi, esattamente com’era in Montery o macOS precedenti. Continuo però a non capire cosa sia successo dentro macOS per rendere così inefficienti i dischi formattai con HFS+. Non credo che Apple l’abbia fatto apposta per spingere gli utenti a passare al nuovo filesystem, è molto più probabile che sia un banale bug che Apple non ha interesse a correggere.

La mia personale esperienza con la conversione da HFS+ a APFS conta meno di zero dal punto di vista statistico, però mi sembra ragionevole poter affermare che quando il disco da convertire è relativamente vuoto, diciamo fino al 50%, il processo di conversione non dovrebbe creare problemi. Non lo dico per aver guardato nella palla di cristallo, ma per la semplice ragione che in queste condizioni macOS ha ampio spazio per creare le strutture dati del nuovo filesystem senza toccare quelle già esistenti.

Al di sopra di quest limite il discorso cambia, la conversione potrebbe funzionare oppure, come è successo a me, potrebbe dare errori. E in quel caso è inutile rischiare, meglio fare un backup preventivo piuttosto che perdere i propri documenti o doversi infognare in astrusi processi di riparazione che non si sa mai come (e quando) finiscono.

C’è chi ama vivere sul filo del rasoio e considera il backup una perdita di tempo. Ma non è così, il backup non è mai una perdita di tempo, è una assicurazione sui propri dati. E, a differenza dele normali assicurazioni, è gratis o quasi.

In ogni caso, mai spaventarsi se succede qualche imprevisto. Meglio fare una pausa, pensarci su, cercare informazioni in rete, perché reagire (male) d’istinto può fare più danni di quelli che ci sono già.