Krótka odpowiedź
Wybierz ext4 i zamontuj go z discard
opcją obsługi TRIM lub użyj FITRIM (patrz poniżej). Skorzystaj również z tej noatime
opcji, jeśli obawiasz się „zużycia SSD”.
Nie zmieniaj domyślnego harmonogramu we / wy (CFQ) na serwerach z wieloma aplikacjami , ponieważ zapewnia to uczciwość między procesami i ma automatyczną obsługę SSD. Jednak należy użyć terminu na komputerach stacjonarnych, aby uzyskać lepszą szybkość reakcji pod obciążeniem.
Aby łatwo zagwarantować prawidłowe wyrównanie danych, początkowy sektor każdej partycji musi być wielokrotnością 2048 (= 1 MiB). Możesz użyć ich fdisk -cu /dev/sdX
do utworzenia. W ostatnich dystrybucjach automatycznie zajmie się tym za Ciebie.
Zastanów się dwa razy, zanim użyjesz funkcji wymiany na dysku SSD. Prawdopodobnie będzie znacznie szybszy w porównaniu do wymiany na HDD, ale szybciej zużyje dysk (co może nie mieć znaczenia, patrz poniżej).
Długa odpowiedź
Ext4 to najpopularniejszy system plików Linux (dobrze utrzymany). Zapewnia dobrą wydajność z dyskiem SSD i obsługuje funkcję TRIM (i FITRIM), aby utrzymać dobrą wydajność SSD w czasie (to usuwa nieużywane bloki pamięci, aby umożliwić późniejszy dostęp do zapisu). NILFS jest specjalnie zaprojektowany dla napędów pamięci flash, ale tak naprawdę nie działa lepiej niż ext4 na testach porównawczych. Btrfs jest wciąż uważane za eksperymentalne (i naprawdę nie lepiej wykonać albo ).
Funkcja TRIM usuwa bloki SSD, które nie są już używane przez system plików. Pozwoli to zoptymalizować długoterminową wydajność zapisu i jest zalecane na dyskach SSD ze względu na ich konstrukcję. Oznacza to, że system plików musi być w stanie powiedzieć napędowi o tych blokach. Opcja discard
montowania ext4 wyda takie polecenia TRIM , gdy bloki systemu plików zostaną zwolnione. To jest odrzucenie online .
Jednak takie zachowanie pociąga za sobą niewielki narzut wydajności. Od Linuksa 2.6.37 możesz uniknąć używania discard
i wyboru sporadycznego odrzucania wsadowego za pomocą FITRIM (np. Z crontab). fstrim
Narzędzie robi to (online), jak również -E discard
opcję fsck.ext4
. Będziesz jednak potrzebował „najnowszej” wersji tych narzędzi.
Możesz ograniczyć zapisy na dysku, ponieważ dysk SSD ma pod tym względem ograniczony okres użytkowania. Nie martw się jednak zbytnio , dzisiejszy najgorszy dysk SSD 128 GB może obsługiwać co najmniej 20 GB zapisanych danych dziennie przez ponad 5 lat (1000 cykli zapisu na komórkę). Lepsze (a także większe) mogą trwać znacznie dłużej: najprawdopodobniej do tego czasu je zastąpisz.
Jeśli chcesz użyć wymiany na dysku SSD, jądro zauważy dysk nieobrotowy i losowo wykorzysta zamianę (wyrównanie zużycia na poziomie jądra): SS
po włączeniu zamiany zobaczysz komunikat (Solid State) w jądrze:
Dodanie wymiany 2097148k na / dev / sda1. Priorytet: -1 w zakresie: 1 w poprzek: 2097148k SS
Ponadto zgadzam się z większością odpowiedzi na aliasgar (nawet jeśli większość z nich została - nielegalnie? - skopiowana z tej witryny ), ale częściowo muszę się nie zgodzić z częścią dotyczącą harmonogramu . Domyślnie harmonogram terminów jest zoptymalizowany dla dysków obrotowych, ponieważ implementuje algorytm windy . Wyjaśnijmy więc tę część.
Długa odpowiedź na harmonogramach
Począwszy od jądra 2.6.29, dyski SSD są automatycznie wykrywane i możesz to sprawdzić za pomocą:
cat /sys/block/sda/queue/rotational
Powinieneś dostać 1
na dyski twarde i 0
na SSD.
Teraz program planujący CFQ może dostosować swoje zachowanie na podstawie tych informacji. Od Linuksa 3.1 cfq-iosched.txt
plik dokumentacji jądra mówi :
CFQ ma pewne optymalizacje dla dysków SSD, a jeśli wykryje nierotacyjne nośniki, które mogą obsługiwać większą głębokość kolejki (wiele żądań w locie na raz), [...].
Ponadto harmonogram Ostatecznego terminu próbuje ograniczyć nieuporządkowane ruchy głowy na dyskach obrotowych w oparciu o numer sektora. Cytując dokument jądra deadline-iosched.txt
, fifo_batch
opis opcji :
Żądania są pogrupowane w `` partie '' określonego kierunku danych (odczyt lub zapis), które są obsługiwane w rosnącej kolejności sektorów.
Jednak dostosowanie tego parametru do 1 podczas korzystania z dysku SSD może być interesujące:
Ten parametr dostraja równowagę między opóźnieniem na żądanie a zagregowaną przepustowością. Gdy głównym problemem jest małe opóźnienie, mniejsze jest lepsze (gdzie wartość 1 powoduje zachowanie kolejności zgłoszeń). Zwiększenie partii fifo_batch ogólnie poprawia przepustowość kosztem zmian opóźnienia.
Niektóre testy porównawcze sugerują, że istnieje niewielka różnica w wydajności między różnymi programami planującymi. Dlaczego więc nie zalecić uczciwości ? kiedy CFQ rzadko jest zły na ławce . Jednak w konfiguracjach pulpitu zazwyczaj można uzyskać lepszą szybkość reakcji przy użyciu terminu pod obciążeniem, ze względu na jego konstrukcję (prawdopodobnie jednak przy niższych kosztach przepustowości).
To powiedziawszy, lepszym punktem odniesienia byłoby spróbowanie użycia terminu z fifo_batch=1
.
Aby domyślnie używać terminu na dyskach SSD, możesz utworzyć plik, powiedz /etc/udev.d/99-ssd.rules
w następujący sposób:
# all non-rotational block devices use 'deadline' scheduler
# mostly useful for SSDs on desktops systems
SUBSYSTEM=="block", ATTR{queue/rotational}=="0", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/scheduler}="deadline"
gdisk
&grub 2.0.x
(chyba ktoś wspomniał o tym poniżej w odpowiedzi), a MBR jest starszą metodą używającą starejgrub 0.9.7
ifdisk
.. można znaleźć więcej tutaj: wiki.archlinux.org/index.php/Solid_State_Drives