Оптимізований ZFS в умовах низької оперативної пам'яті?

Наразі я налаштовую файловий сервер і дійсно налаштував накопичувачі даних. У системі є 4 накопичувачі (один диск ОС, 3 диски даних). Диск ОС відформатований як ext4 і не буде доданий до пулу ZFS (якщо я вирішу запустити ZFS). Основна проблема - цілісність даних та мінімальний ризик втрати даних (кешування диска вимкнено у біосах). Для цього ZFS, здається, є ідеальним кандидатом, оскільки він має стабільну версію для Linux (правильно?), А також підтримує дублювання даних, об'єднання та raidz, де жорсткі диски не повинні бути однакового розміру.

Але ось моя проблема. Сервер має лише 2 Гб оперативної пам’яті, і це не може бути оновлено найближчим часом, і реально лише 1,5 фактично будуть доступні ZFS після того, як я встановлю всі інші сервіси. Максимум близько 10 клієнтів будуть користуватися ним будь-коли (більше, як 4 в середньому). Це занадто низько, щоб вважати його безпечним?

Як я розумію, ZFS може вийти з ладу в умовах низької оперативної пам’яті і взяти пул із собою. Я чув суперечливі думки, чи допоможе своп полегшити цю проблему (у мене є виділений накопичувач розміром 20 ГБ). Хто-небудь відчував втрату даних із ZFS з невеликою кількістю оперативної пам’яті та які оптимізації ви включили для запобігання цього?

Зважаючи на вищесказане, чи можна було б все-таки запустити ZFS, хоча зменшити розмір акка та трохи зменшити його чи це буде занадто ризиковано?

Характеристики системи: ОС 2 ГБ оперативної пам’яті 20 Гб своп-накопичувача, Debian 7, мінімальна установка, з FTP, і XBMC, DNLA, (щоб дати уявлення про потребу в ОЗУ). Використовується для передачі потоку серверів і музичних носіїв інформації на інші пристрої.

Ви заявляєте цілісність даних та мінімальний ризик втрати даних як основні проблеми. Запуск ZFS з лише 2 Гбіт оперативної пам’яті є ризикованим і недоцільним. Занадто мало оперативної пам’яті вбиває продуктивність і стало причиною численних незмінних пулів у минулому. Проект FreeNAS зазначає як мінімум 8 ГБ оперативної пам’яті.

Крім того, оскільки ви турбуєтеся про втрату даних, вам потрібно буде використовувати оперативну пам’ять ECC. Оскільки ваш ящик може підтримувати лише 2 Гбіт оперативної пам’яті, я вважаю, що це дійсно стара коробка, яка не буде хорошим вибором для ZFS.

Щоб відповісти на ваші запитання:

[…] Та підтримує дублювання даних

На практиці забудьте про дедуплікацію, коли у вас немає хоча б 32GiB, як правило. Можливо, вам знадобиться значно більше оперативної пам’яті, залежно від розміру пулу. По-друге, зробіть математику, якщо дедуплікація + оперативна пам'ять коштує дешевше, ніж кілька додаткових дисків. Найчастіше більше дисків є дешевшою альтернативою.

Це занадто низько, щоб вважати його безпечним?

Так, це занадто низько.

Як я розумію, ZFS може вийти з ладу в умовах низької оперативної пам’яті і взяти пул із собою.

Це правда, і багато людей втратили пул через низьку оперативну пам’ять.

Я чув суперечливі думки, чи допоможе своп полегшити цю проблему

Забудьте про своп, ваш вікно ZFS ніколи не повинен використовувати своп.

EDIT: Якщо ви відчуваєте пригоди і не заперечуєте проти ризику виникнення паніки або втрати даних, прочитайте посібник з налаштування ZFS та адаптуйте згадані налаштування. Ось приклад налаштувань для системи 768MiB пам'яті.

vm.kmem_size="330M"
vm.kmem_size_max="330M"
vfs.zfs.arc_max="40M"
vfs.zfs.vdev.cache.size="5M"

Інакше вкладіть сто доларів у смужку пам’яті та насолоджуйтесь стабільною та ефективною системою.

У системах високого тиску пам'яті (Linux) дійсно потрібно оновити пам'ять. Все ще є помилка ( посилання ), де свопінг блокує IO (завдання, яке вивішене ядро), що робить його непридатним, якщо не перезавантажено. Я вважаю, що vm.swappiness = X не впливає на zfs, тому обмеження дуги певним числом може трохи допомогти.