Zoptymalizowany ZFS w środowisku o niskiej pamięci RAM?

Obecnie konfiguruję serwer plików i doszedłem do tego, że faktycznie skonfigurowałem dyski danych. System ma 4 dyski (jeden dysk systemu operacyjnego, 3 dyski danych). Dysk OS jest sformatowany jako ext4 i nie zostanie dodany do puli ZFS (jeśli wybiorę uruchomienie ZFS). Moim głównym problemem jest integralność danych i minimalne ryzyko utraty danych (buforowanie dysku jest wyłączone w BIOS). Do tego ZFS wydaje się być idealnym kandydatem, ponieważ ma stabilną wersję dla Linuksa (prawda?) I obsługuje duplikację danych, tworzenie puli i podnoszenie, gdzie dyski twarde nie muszą być tego samego rozmiaru.

Ale oto mój problem. Serwer ma tylko 2 GB pamięci RAM i nie można go zaktualizować w najbliższej przyszłości, a realistycznie tylko 1,5 będzie faktycznie dostępne dla ZFS po zainstalowaniu wszystkich innych usług. Jednocześnie może z niego korzystać maksymalnie około 10 klientów (więcej niż średnio 4). Czy to jest zbyt niskie, aby uznać za bezpieczne?

Z tego, co rozumiem, ZFS może ulec awarii w sytuacjach niskiej pamięci RAM i zabrać ze sobą pulę. Słyszałem, że opinie, które wymieniają, czy zamiana pomoże w rozwiązaniu tego problemu (mam dysk o pojemności 20 GB). Czy ktoś doświadczył utraty danych z ZFS z małą pamięcią RAM i jakie optymalizacje wprowadziłeś, aby temu zapobiec?

Biorąc pod uwagę powyższe, czy nadal można uruchomić ZFS, choć zmniejszyć rozmiar potwierdzenia i nieco go przyciąć, czy będzie to zbyt ryzykowne?

Specyfikacje systemu: 2 GB pamięci RAM 20 GB z wymiennym napędem, Debian 7, minimalna instalacja, z FTP i XBMC, DNLA, (aby dać wyobrażenie o wymaganej pamięci RAM). Służy do przesyłania strumieniowego z serwera pamięci i multimediów muzycznych do innych urządzeń.

Za główne obawy uznajesz integralność danych i minimalne ryzyko utraty danych. Uruchamianie ZFS tylko z 2GiB pamięci jest ryzykowne i niewskazane. Zbyt mała pamięć RAM zabija wydajność i była przyczyną wielu niezliczonych pul w przeszłości. Projekt FreeNAS określa co najmniej 8 GB pamięci RAM.

Ponadto, ponieważ twoja obawa dotyczy utraty danych, będziesz chciał użyć ECC RAM. Ponieważ twoje urządzenie obsługuje tylko 2 GB pamięci RAM, zakładam, że jest to naprawdę stare urządzenie, które nie byłoby dobrym wyborem dla ZFS.

Aby odpowiedzieć na twoje pytania:

[…] I obsługuje kopiowanie danych

W praktyce zapomnij o deduplikacji, gdy nie masz co najmniej 32GiB, jako ogólną zasadę. W zależności od wielkości puli może być potrzebne znacznie więcej pamięci RAM. Po drugie, wykonaj matematykę, jeśli koszty deduplikacji i pamięci RAM są tańsze niż garść dodatkowych dysków. Najczęściej dyski są tańszą alternatywą.

Czy to jest zbyt niskie, aby uznać za bezpieczne?

Tak, jest zdecydowanie za nisko.

Z tego, co rozumiem, ZFS może ulec awarii w sytuacjach niskiej pamięci RAM i zabrać ze sobą pulę.

To prawda i wiele osób straciło swoje pule z powodu niskiej pamięci RAM.

Słyszałem, że opinie są sprzeczne, czy zamiana pomoże w rozwiązaniu tego problemu

Zapomnij o zamianie, twoje pole ZFS nigdy nie powinno używać zamiany.

EDYCJA: Jeśli masz ochotę na przygodę i nie masz nic przeciwko ryzyku okazjonalnej paniki lub utraty danych, przeczytaj przewodnik strojenia ZFS i dostosuj wspomniane ustawienia. Oto przykładowe ustawienia dla systemu 768 MB pamięci.

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

W przeciwnym razie zainwestuj sto dolarów w pasek pamięci i ciesz się stabilnym i wydajnym systemem.

W systemach wysokiego ciśnienia pamięci (Linux) naprawdę konieczne jest uaktualnienie pamięci. Nadal występuje błąd ( link ), w którym zamiana blokuje IO (zadanie zawieszone w jądrze), uniemożliwiając jego użycie, chyba że zostanie ponownie uruchomiony. Wierzę, że vm.swappiness = X nie ma wpływu na zfs, więc ograniczenie łuku do pewnej liczby może trochę pomóc.