Robiłem takie rzeczy od lat i prawdopodobnie mogę pomóc ci uniknąć tych samych bólów, które przeżyłem.
Przechowywanie w chmurze byłoby idealne dla niektórych przypadków użycia, ale szkicowe w kwestii prywatności / bezpieczeństwa bez dodatkowej pracy i niekoniecznie odpowiednie dla przypadków użycia obejmujących dużą ilość danych. (Pracowałem nad problemami bezpieczeństwa / prywatności z przezroczystym szyfrowaniem plików i używam tego równolegle z rozwiązaniem, które przedstawiłem poniżej, dla różnych przypadków użycia).
Oto lokalne rozwiązania do przechowywania w rosnącej kolejności żywotności (która jest z natury subiektywna i zależna od konkretnych przypadków użycia):
- exFAT: Na dole tylko z powodu mojego własnego braku doświadczenia i względnej nowości. Istnieją problemy z kompatybilnością między platformami z powodu różnych rozmiarów bloków. Najwyraźniej formatowanie dysku w systemie Windows z blokiem mniejszym niż 1024 bajty może działać.
- NTFS: Miałem różnego rodzaju problemy z NTFS-3G, przechodząc tam iz powrotem między Windows, Mac i Linux. Uszkodzenie plików, utrata danych itp. To było kilka lat temu, może teraz jest lepiej - ale wtedy było „sprzedane” jako solidne i nie było.
- FAT32: Z mojego doświadczenia wynika, że jest to jedyny prawdziwie „wieloplatformowy” system plików, który może łączyć komputery Mac, Linux i Windows. (A kamery i telewizory, a ...) Jest per-limit wielkości pliku 4GB i 2TiB całkowita objętość limit rozmiaru . Teoretycznie możesz pokonać ograniczenie 32 GB FAT32 za pomocą Fat32Formatter , ale nie wiem, jak kompatybilny jest w różnych systemach. Teoretycznie FAT + pozwala na pliki 256GiB i użycie większego rozmiaru bloku
- Maszyna wirtualna współdzieląca swój macierzysty system plików z systemem operacyjnym hosta za pośrednictwem CIFS: Jest to najlepsze rozwiązanie dla większości moich przypadków użycia.
Wiele lat temu, gdy miałem już dość niszczenia danych przy użyciu NTFS-3G, zacząłem używać małej maszyny wirtualnej z systemem Windows 2000 i udostępniłem wolumin NTFS „natywnie” systemowi hostowi za pośrednictwem CIFS. Wydajność nie może się równać z bezpośrednio podłączoną pamięcią, ale w końcu muszę pożegnać się z uszkodzeniem danych oraz z powodu nieufności i bólów głowy. System NTFS sformatowany z systemu Windows 2000 działał bezbłędnie i zamiennie z bardziej nowoczesnymi wersjami systemu Windows, w tym przełączając się między Windows 2000 na maszynie wirtualnej i Windows Vista (w tym czasie).
Mimo to NTFS po prostu nie był wystarczająco solidny, aby niezawodnie przechowywać ogromne ilości danych przez długi czas, nawet jeśli jest w konfiguracji lustrzanej (a zwłaszcza w konfiguracji RAID5). Głównie z powodu bitrotu i braku sumowania. To prawda, była to najlepsza rzecz na długi czas, ale już nie.
Teraz jedynym używanym przeze mnie „wieloplatformowym” systemem plików jest ZFS, prezentowany przez CIFS przez Linux działający na maszynie wirtualnej. (Coraz częściej używam BTRFS, który ostatnio wydaje się przekroczyć pewien próg stabilności w moich przypadkach użycia. Przez długi czas korzystałem z niego tylko eksperymentalnie i często mnie zawiodłem.)
Nie używam ZFS dla Mac OS, tylko ZFS na Linuksie. (Kiedyś używałem maszyny wirtualnej OpenSolaris do hostowania ZFS ze względu na czystość i obsługę najbardziej aktualnych funkcji ZFS, dopóki Oracle nie pomylił się).
Próbowałem ZFS na Maca jakiś czas temu i było to zbyt niestabilne i nieaktualne. Może teraz jest w porządku, ale moje rozwiązanie VM jest bezbłędne. I tak jak powiedziałem, coraz częściej używam BTRFS, co jest lepsze pod wieloma względami dla moich wymagań (z których najważniejszą jest niesamowita niezawodność - którą ZFS zawsze zapewniał).
Uruchamiam trzykrotnie komputery Mac, a gdy nie uruchamiam natywnie Linuksa, uruchamiam tę samą natywną instalację Linuksa na maszynie wirtualnej. Linux jest całkowicie zadowolony na przemian z uruchamiania na maszynie wirtualnej z dodatkami gości i natywnie. Prawie zawsze uruchamiam maszynę wirtualną z systemem Linux w celu uzyskania „natywnego” dostępu do woluminu ZFS lub BTRFS za pośrednictwem CIFS, gdy nie jest on uruchamiany natywnie.
Bezproblemowo dostosowałem większość przepływów pracy, aby uwzględnić wolniejszy dostęp CIFS do dużej niezawodnej pamięci masowej na wielu platformach. Na przykład, jeśli potrzebuję szybkiego dostępu do wielu działających danych, zwykle jest to aplikacja unikalna dla tego konkretnego systemu operacyjnego hosta i nie musi być dostępna na różnych platformach. Używam więc tylko lokalnej pamięci SSD, jaką system operacyjny jest dostępny natywnie, i robię regularne kopie do wolniejszej pamięci „wieloplatformowej” - lub tylko po zakończeniu projektu, w zależności od konkretnego przypadku użycia.
Wskazówka: jeśli wybierzesz trasę VM, będziesz miał ochotę współużytkować system plików VM przez mostkowany adapter. Zaletą tego jest to, że maszyna wirtualna będzie miała własny adres IP w tej samej podsieci, a pamięć będzie dostępna nawet dla innych komputerów w tej podsieci. Wady mostka przejściowego są jednak następujące: 1) Jest on powiązany z konkretnym adapterem fizycznym i jeśli przejdziesz z, powiedzmy, przewodowego na bezprzewodowy, możesz stracić połączenie internetowe z poziomu maszyny wirtualnej [co jest problemem tylko wtedy, gdy używanie maszyny wirtualnej jako systemu operacyjnego, jak zwykle]. I 2) Mostkowane adaptery mogą być wybredne. Czasami „po prostu działa”, ale jeśli masz problemy, rozwiązywanie problemów może być dość nieuporządkowane. Lepszym rozwiązaniem jest skonfigurowanie maszyny wirtualnej za pomocą dwóch adapterów: A) NAT [dla dostępu do Internetu z maszyny wirtualnej, która będzie działać bez względu na to, jaki fizyczny adapter ją zapewnia], i B) Tylko host, skonfigurowany ze statycznym adresem IP, bez DNS lub bramy, adaptera virtio i w trybie rozwiązłym. Tylko twój komputer lokalny będzie miał dostęp do udziałów CIFS maszyny wirtualnej. Konfiguracja tego rozwiązania nie jest trywialna, ale kiedy to zrobisz, jest to w zasadzie magia.
Powodzenia!