Czy powinienem używać btrfs lub Ext4 dla mojego dysku SSD?

Czy powinienem używać btrfs (z opcjami discard, compress = lzo i space_cache) lub Ext4 (z opcją discard) dla SSD dla mojej partycji root na pulpicie komputera Ubuntu 11.10 (Oneiric) amd64 mojej maszyny biurowej?

/ home będzie dyskiem twardym, więc niezawodność fs wpływa na system operacyjny, a nie na moje dane.

Według testów phoronix zawsze zależy to od wielu czynników. W jednym przypadku Btrfsbędzie znacznie lepiej niż EXT4podczas odczytu dużych plików na dysku SSD. Podobnie, biorąc pod uwagę wydajność transakcji na dysku, Ext4może działać lepiej niż później.

Możesz przejrzeć te testy tutaj , tutaj i tutaj (OSTRZEŻENIE: Długie artykuły).

Podsumowując, Btrfs nie ma obecnie przewagi ilościowej nad systemem plików EXT4 , nawet w trybie SSD.

Możesz na razie dokonać wyboru Ext4.

Dla tych, którzy natkną się na to pytanie w 2016 roku ... Użyj ext4. Próbowałem btrfs i różnica jest znacząca. W ciągu 10 dni zapisywanie operacji we / wy na ext4 wyniosło 17 800 sektorów. Btrfs? 490 400 sektorów. Ten sam dysk SSD, identyczny system plików, różne partycje. Zasadniczo to samo obciążenie pracą.

Zarówno ext4, jak i btrfs „cicho”, gdy na dysku jest zero operacji zapisu. Dobre.

Ext4 zapisze zmodyfikowane dane plus pewne koszty ogólne. Koszty ogólne dotyczą zapisanych danych. Zapis 4K (1 blok) przesuwa około 50-80 bloków narzutu przy następnym zatwierdzeniu. (Dziennik ext4 jest w pełni włączony)

Zmodyfikuj pojedynczy blok 4K na btrfs, a przy następnym zatwierdzeniu przepchniesz między 4000-5000 bloków narzutu. Domyślnie zatwierdzenie wynosi 30 sekund. Użyłem 120.

Teraz zależy to od sposobu korzystania z dysku SSD. Jako root istnieje zwykle dość stały, niski poziom strumienia zapisów. Pliki dziennika, pliki driftu ntp, odbudowy man db, aktualizacje topologii opensm itp. Każde zdarzenie spowoduje uszkodzenie dysku btrfs kolejnymi zapisami 4000-5000.

Powyższe 10-dniowe liczby dotyczą mojego dysku SSD z ograniczeniem zapisu. Większość tych 17 800 sektorów była wynikiem niewielkiej aktualizacji systemu. Jedna kopia btrfs nie ucierpiała. Moimi pisarzami są właśnie drift ntp, topologia opensm i aktualizacje man db (co noc). Nic innego nie uderza w ten dysk, z wyjątkiem aktywnie inicjowanych rzeczy, takich jak aktualizacje systemu vim /etc/whateveritp.

Na całych dyskach SSD będzie naprawdę dużo zapisów. Po prostu nie widzę sensu w ich marnowaniu, ponieważ media podążają za królikami i tęczami. Jeśli chcesz zapłacić tę cenę za COW, idź po nią. Nie chodzi o „wydajność”. Jest to dysk SSD i prawdopodobnie mógłbyś umieścić na nim najgorszy „system plików” znany człowiekowi i nadal uzyskać pewien poziom wydajności - tylko brutalną siłą. Ext4 nie jest zdecydowanie najgorszym znanym systemowi plików.

Brak comiesięcznej kontroli FS. Wypróbuj poniższy skrypt. Jest to 100% włamanie, nie będzie działać dla punktów montowania MD,

#! /bin/bash
dev=`cat /proc/mounts | grep " $1 " | awk '{print $1}'`
x=`basename $dev`
vmnam=`lsblk $dev -o MOUNTPOINT,PKNAME | grep "$1" | awk '{print $2}'`
vmx=`vmstat -d | grep $vmnam | awk '{print $8}'`
lbax=`smartctl -a $dev | grep LBA | awk '{print $10}'`
tmpnam=`mktemp XXX`
echo "Tracking device: $dev, mounted on $1 (vmstat on $vmnam)"
tim=`date +%s`
timx=`date +%s`
while true
do
    vm=`vmstat -d | grep "$vmnam" | awk '{print $8}'`
    lba=`smartctl -a $dev | grep LBA | awk '{print $10}'`
    if [ "$vm" != "$vmx" ]
    then
        tim=`date +%s`
        dif=`dc <<< "$vm $vmx - p"`
        lbad=`dc <<< "$lba $lbax - p"`
        timd=`dc <<< "$tim $timx - p"`
        echo `date` " (sec=$timd) writes=$vm (dif=$dif) (lba=$lbad)"
        vmx="$vm"
        lbax="$lba"
        timx="$tim"
        find "$1" -mount -newer "$tmpnam" -print | grep -v "/tmp"
        touch "$tmpnam" 
    fi
    sleep 1 
done

Powie ci, ile bloków zostało napisanych, zgodnie z samym napędem i dokładnie, które pliki zostały zaktualizowane. Potrzebuje uprawnień roota. Sam zobacz. Uruchomiam SSD na głównym systemie plików i wywołuję skrypt stat.sh. Więc...sudo ./stat.sh /

Ostatnim razem, gdy go testowałem i nigdzie nie słyszałem inaczej, ext4 zjada media półprzewodnikowe. (pendrive'y, dyski SSD itp.) Nie polecam używać go na takim urządzeniu. Zamiast tego użyj ext3. W większości przypadków na dyskach SSD i tak nie będziesz w stanie stwierdzić różnicy.

BTRFS nie jest jeszcze całkiem stabilny. Jest jednak wystarczająco stabilny do zastosowań niekrytycznych. Tego właśnie używam do tworzenia rozruchowych dysków flash. Jeśli użyjesz kompresji = zlib i ssd jako opcji montowania, kompresja zrekompensuje niższe prędkości zapisu większości nośników półprzewodnikowych, a ssd zmieni algorytm alokacji na taki, który działa znacznie lepiej na takich urządzeniach i zrekompensuje wszelkie słabe wyrównanie zużycia przez sprzęt. Jedynym obszarem wydajności, który wciąż stanowi problem, jest to, że synchronizacja połączeń jest powolna. Nie jest to problem do ogólnego użytku, ale połączenia dpkg synchronizują się po każdej operacji, więc instalacja i aktualizacja oprogramowania może być powolna. BTRFS oferuje także migawki i inne zaawansowane funkcje, które są w niektórych przypadkach całkiem przydatne.

Jeśli zdecydujesz się na BTRFS, koniecznie użyj dystrybucji za pomocą jądra 3.2.0-2 lub nowszego. 3.1.x jest wykonalne w razie potrzeby. W przypadku starszych jąder musisz samodzielnie skompilować najnowsze moduły BTRFS. Wbudowane są prawie stabilne, ale korekcja błędów nie działa w starszych wersjach, co może dać ci potok, jeśli coś pójdzie nie tak. Najnowsze wersje mają fsck, który może naprawiać najczęstsze błędy.

Ostatnie ostrzeżenie, słyszałem doniesienia, że ​​pliki wymiany w systemie plików BTRFS spowodują jego uszkodzenie. Ten problem mógł zostać rozwiązany, ale należy go dokładnie sprawdzić przed jego wdrożeniem.

Jeśli potrzebujesz pomocy w skonfigurowaniu konfiguracji BTRFS tak, jak chcesz, daj mi znać. Zrobiłem kilka szalonych, które działają całkiem nieźle na konkretne rzeczy.

Nie używałbym ext4 na dysku SSD opartym na anegdotycznych dowodach i moim własnym doświadczeniu, które sugeruje, że ext4 może znacznie skrócić żywotność dysku SSD ze względu na liczbę odczytów i zapisów związanych z systemem plików. W jednym z artykułów, które ostatnio czytałem, zasugerowałem, że niezoptymalizowany (uwzględniający rozmiar strony itp.) Ext4 na dysku SSD może skrócić żywotność dysku o połowę. Po tygodniu rozwiązywania problemów doszedłem do wniosku, że moje własne dyski SSD przetrwały tylko osiem miesięcy z powodu tego problemu. Jeśli używasz dysku SSD, zapoznaj się ze sposobem optymalizacji systemu plików w oparciu o takie rzeczy, jak rozmiar strony flash, który może być inny niż typowy rozmiar cylindra, dla którego system plików jest skonfigurowany.