Я займався подібними справами роками і, ймовірно, може допомогти вам уникнути тих же болів, які я переживав.
Хмарне сховище було б ідеальним для деяких випадків використання, але схематичне щодо конфіденційності / безпеки без додаткових робіт, і не обов’язково підходить для випадків використання, що містять велику кількість даних. (Я працював над проблемами безпеки / конфіденційності з прозорим шифруванням для кожного файлу, і використовую це паралельно з рішенням, описаним нижче, для різних випадків використання.)
Ось локальні рішення щодо зберігання, що збільшують порядок життєздатності (що за своєю суттю є суб'єктивним та залежить від конкретних випадків використання):
- exFAT: Внизу лише через мою відсутність досвіду роботи з цим та його відносну новизну. Існують проблеми сумісності між платформами через різні розміри блоків. Мабуть, форматування накопичувача в Windows розміром блоку менше 1024 байт може працювати.
- NTFS: У мене виникли всілякі проблеми з NTFS-3G, повертаючись назад і назад між Windows, Mac та Linux. Пошкодження файлів, втрачені дані тощо. Це було кілька років тому, можливо, це зараз краще - але його "продавали" як міцне, і не було.
- FAT32: На мій досвід, це єдина справді "кросплатформна" файлова система, яка може з'єднати Mac, Linux та Windows. (І камери, і телевізори, і ...) Існує окремо для кожного файл 4 Гб обмеження на розмір і 2TiB загального обсягу граничного розміру . Теоретично ви можете подолати обмеження на 32 Гб FAT32 за допомогою Fat32Formatter , але я не знаю, наскільки він сумісний у всіх системах. Теоретично FAT + дозволяє створювати 256GiB файлів та використовувати більш високий розмір блоку
- Віртуальна машина, що обмінюється своєю рідною файловою системою на хост-OS через CIFS: Це найкраще рішення для більшості випадків мого використання.
Роки тому, коли я втомився від пошкодження даних за допомогою NTFS-3G, я почав використовувати невелику віртуальну машину під управлінням Windows 2000 і поділився томом NTFS "споконвічно" на хост-OS через CIFS. Продуктивність не може порівнятись із безпосередньо приєднаним сховищем, але я нарешті попрощався з корупцією даних та недовірою та головними болями, які вона викликала. NTFS, відформатований з Windows 2000, бездоганно та взаємозамінно працював із більш сучасними версіями Windows, включаючи перемикання вперед та назад між Windows 2000 у VM та Windows Vista (у той час).
Але все-таки NTFS просто не був достатньо надійним для надійного зберігання величезних обсягів даних протягом тривалих періодів часу, навіть якщо в дзеркальній конфігурації (і особливо в конфігурації RAID5). В основному через бітрот та відсутність контрольної суми. Зрозуміло, це було найкращою справою довгий час, але вже не більше.
Тепер єдина "кросплатформна" файлова система, яку я використовую, - це ZFS, представлений через CIFS Linux, що працює в VM. (Я також все частіше використовую BTRFS, який останнім часом, здається, переступив деякий поріг стійкості для моїх випадків використання. Тривалий час я використовував його лише експериментально, і це часто мене підводило.)
Я не використовую ZFS для Mac OS, лише ZFS в Linux. (Раніше я використовував OpenSolaris VM для розміщення ZFS заради чистоти та підтримки самих сучасних функцій ZFS, поки Oracle не змішав це.)
Я спробував ZFS для Mac деякий час назад, і це було занадто нестабільно і застаріло. Можливо, це нормально, але моє рішення VM є бездоганним. І як я вже говорив, все одно я все частіше використовую BTRFS, що є кращою відповідністю моїм вимогам (перше і головне - надійність у скелі - яку завжди забезпечував ZFS).
Я потрійно завантажую свої Macs, і коли я не запускаю Linux в оригінальному режимі, я запускаю ту саму рідну інсталяцію Linux у VM. Linux цілком задоволений тим, що чергує між запусками у віртуальній машині з гостьовими доповненнями та власними. Я майже завжди запускаю Linux VM для "рідного" доступу до томів ZFS або BTRFS через CIFS, коли не запускає його власне.
Я безперебійно налаштував більшість моїх робочих процесів, щоб забезпечити більш повільний доступ CIFS до великих надійних сховищ для "платформ". Наприклад, якщо мені потрібен швидкий доступ до безлічі робочих даних, це зазвичай у додатку, який є унікальним для конкретної хост-операційної системи, і йому не потрібно бути доступним на будь-яких платформах. Тому я просто використовую будь-який швидкий локальний SSD-накопичувач, операційна система доступна в оригінальному режимі, і роблю звичайні копії на повільніші "міжплатформові" сховища - або лише тоді, коли проект виконаний, залежно від конкретного випадку використання.
Порада: Якщо ви дійдете по маршруту VM, ви будете спокушені поділитися файловою системою VM через мостовий адаптер. Перевага в тому, що VM матиме власну IP-адресу в тій самій підмережі, а сховище буде доступним навіть для інших комп'ютерів у цій підмережі. Однак недоліки мостового адаптера є 1) Він пов'язаний з певним фізичним адаптером, і якщо ви перейдете, скажімо, з провідного бездротового зв'язку, ви можете втратити підключення до Інтернету зсередини VM [це лише проблема, якщо ви також використання VM як вашої ОС продуктивності, як я зазвичай це роблю]. І 2) Мостові адаптери можуть бути вибагливими. Іноді це "просто працює", але якщо у вас є проблеми, усунення несправностей може бути досить безладним. Краще рішення - налаштувати VM на два адаптери: A) NAT [для доступу до Інтернету з VM, який буде працювати незалежно від того, який фізичний адаптер його надає], і B) Тільки для хоста, налаштований зі статичною IP-адресою, без DNS або шлюзу, адаптером virtio та в безладному режимі. Тільки ваша локальна машина зможе отримати доступ до CIFS-акцій VM. Не налаштовувати налаштування цього рішення, але як тільки ви це зробите, це в основному магія.
Удачі!