Ho fatto questo genere di cose per anni e probabilmente posso aiutarti a evitare gli stessi dolori che ho attraversato.
Il cloud storage sarebbe ideale per alcuni casi d'uso, ma impreciso sulla privacy / sicurezza senza lavoro aggiuntivo e non necessariamente adatto per casi d'uso che coinvolgono una grande quantità di dati. (Ho risolto i problemi di sicurezza / privacy con la crittografia trasparente per file e lo uso in parallelo con la soluzione che ho descritto di seguito, per diversi casi d'uso.)
Ecco le soluzioni di archiviazione locale in ordine crescente di fattibilità (che è intrinsecamente soggettiva e dipendente da specifici casi d'uso):
- exFAT: In fondo solo per la mia mancanza di esperienza con esso e la sua relativa novità. Esistono problemi di compatibilità tra le piattaforme a causa delle diverse dimensioni dei blocchi. Apparentemente, la formattazione dell'unità in Windows con una dimensione di blocco inferiore a 1024 byte potrebbe funzionare.
- NTFS: Ho avuto tutti i tipi di problemi con NTFS-3G, andando avanti e indietro tra Windows, Mac e Linux. Corruzione dei file, perdita di dati, ecc. Questo è accaduto qualche anno fa, forse ora è meglio - ma è stato "venduto" come solido allora e non lo era.
- FAT32: Nella mia esperienza, questo è l' unico file system veramente "multipiattaforma" in grado di collegare Mac, Linux e Windows. (E fotocamere, TV e ...) C'è un limite di dimensione di 4 GB per file e un limite di dimensione del volume totale di 2 TB . In teoria puoi superare la limitazione FAT32 da 32 GB, con Fat32Formatter , ma non so quanto sia compatibile tra i sistemi. In teoria, FAT + consente file da 256GiB e utilizza blocchi di dimensioni maggiori
- Una macchina virtuale che condivide il suo filesystem nativo con il sistema operativo host tramite CIFS: questa è senza dubbio la migliore soluzione per la maggior parte dei miei casi d'uso.
Anni fa, quando mi sono stufato della corruzione dei dati tramite NTFS-3G, ho iniziato a utilizzare una piccola VM con Windows 2000 e ho condiviso un volume NTFS "nativamente" con il sistema operativo host tramite CIFS. Le prestazioni non possono essere paragonate allo storage direttamente collegato, ma alla fine ho dovuto dire addio alla corruzione dei dati, alla sfiducia e al mal di testa che ha causato. NTFS formattato da Windows 2000, ha funzionato perfettamente e in modo intercambiabile con le versioni più moderne di Windows, incluso il passaggio da Windows 2000 in una VM e da Windows Vista (al momento).
Tuttavia, NTFS non era abbastanza robusto per archiviare in modo affidabile enormi quantità di dati per lunghi periodi di tempo, anche se in una configurazione speculare (e specialmente in una configurazione RAID5). Principalmente a causa di bitrot e mancanza di checksum. Certo, è stata la cosa migliore in circolazione per molto tempo, ma non più.
Ora, l'unico file system "multipiattaforma" che utilizzo è ZFS, presentato tramite CIFS da Linux in esecuzione in una macchina virtuale. (Sto anche usando sempre più BTRFS che recentemente sembra aver varcato una soglia di stabilità per i miei casi d'uso. Per molto tempo l'ho usato solo sperimentalmente e spesso mi ha deluso.)
Non uso ZFS per Mac OS, solo ZFS su Linux. (Utilizzavo una VM OpenSolaris per ospitare ZFS per motivi di purezza e supporto per le funzionalità ZFS più aggiornate, fino a quando Oracle non ha sbagliato.)
Ho provato ZFS per Mac qualche tempo fa ed era troppo instabile e obsoleto. Forse ora va bene, ma la mia soluzione VM è impeccabile. E come ho già detto, sto usando sempre più BTRFS, che è una soluzione migliore in molti modi per le mie esigenze (la prima e soprattutto la solida affidabilità - che ZFS ha sempre fornito).
Avvio triplo i miei Mac e quando non eseguo Linux in modo nativo, eseguo la stessa installazione Linux nativa in una macchina virtuale. Linux è perfettamente felice alternando l'esecuzione in una macchina virtuale con aggiunte guest e nativamente. Quasi sempre eseguo una VM Linux per l'accesso al volume "nativo" ZFS o BTRFS tramite CIFS, quando non lo eseguo in modo nativo.
Ho adattato senza problemi la maggior parte dei miei flussi di lavoro in modo da consentire l'accesso CIFS più lento a un archivio affidabile "multipiattaforma" di grandi dimensioni. Ad esempio, se ho bisogno di un accesso rapido a molti dati di lavoro, di solito si trova in un'applicazione unica per quel particolare sistema operativo host e non deve essere accessibile su più piattaforme. Quindi utilizzo semplicemente lo spazio di archiviazione SSD locale veloce disponibile in modo nativo sul sistema operativo e faccio copie regolari nella memoria "multipiattaforma" più lenta - o solo quando il progetto è terminato, a seconda del caso d'uso specifico.
Suggerimento: se segui la route VM, sarai tentato di condividere il file system VM tramite un adattatore con bridge. Il vantaggio è che la VM avrà il proprio indirizzo IP sulla stessa sottorete e l'archiviazione sarà accessibile anche da altri computer su quella sottorete. Tuttavia, gli svantaggi di un adattatore a ponte sono 1) È legato a un adattatore fisico specifico e se si passa da, diciamo, cablato a wireless, si potrebbe perdere la connettività Internet dall'interno della VM [che è un problema solo se si è anche utilizzo della VM come sistema operativo per la produttività, come faccio di solito]. E 2) Gli adattatori con ponte possono essere pignoli. A volte "funziona", ma se hai problemi, la risoluzione dei problemi può essere piuttosto complicata. Una soluzione migliore è configurare la VM con due adattatori: A) NAT [per l'accesso a Internet dalla VM che funzionerà indipendentemente dall'adattatore fisico che lo fornisce], e B) Solo host, configurato con un indirizzo IP statico, nessun DNS o gateway, adattatore virtio e con modalità promiscua. Solo il tuo computer locale sarà in grado di accedere alle condivisioni CIFS della VM. Non è banale installare questa soluzione, ma una volta fatto è praticamente magico.
In bocca al lupo!