Home  >  linuksowo / ubuntu

Linux z dyskiem SSD za pan brat

Nikt nie lubi wlec się w ogonie postępu, dlatego co jakiś czas nachodzi człowieka nieprzemożona ochota na uaktualnienie konfiguracji swojego komputera. Nachodzi go jeszcze gwałtowniej, gdy taka zmiana niesie za sobą wymierne skutki w jakości pracy, oszczędności energii i poziomu decybeli jakie wydobywają się z naszego cyfrowego kompana. Tym razem wybór padł na dysk SSD – uzasadniony tym, że technologia ta osiągnęła już stan miarę dojrzały, pojemności takich dysków przekroczyły już dawno żartobliwe 32GB, w zamian otrzymujemy niebotyczne osiągi transferu, szybkość startu systemu i aplikacji, jak też pozbywamy się ‘zgrzytania’ dysku talerzowego. Minusem jest przypadłość takich dysków wynikają ze specyfiki nośnika – innymi słowy, im więcej i częściej na tym dysku zapisujemy, tym bardziej skracamy ich żywotność. Ale bez obaw, przypuszczalnie nikomu nie uda się ‘zajeździć’ takiego dysku do czasu wymiany na nowszy model. Ale czy da się coś zrobić, aby Linux był bardziej przyjazny dla dysków SSD? Oczywiście, że się da, nawet mamy do wyboru kilka wariantów postępowania.

0. Trochę teoretyzowania i plan działania

Z uwagi na wrażliwość i ew. ograniczenia żywotności w odniesieniu do częstotliwości zapisu na takim nośniku, logicznym wydaje się przeznaczyć go do takiej roli w naszym pudle, aby zminimalizować występowanie zapisu na dysk Solid State Drive. I o ile można się spierać, czy ma to jakieś uzasadnienie ekonomiczne i wytrzymałościowe, o tyle użytkownicy laptopów i systemów mobilnych nie mają takiego problemu – zwykle mogą wsadzić do urządzenia tylko jeden taki dysk i musi on pełnić rolę pełnoprawnego nośnika. Posiadacze desktopów ‘kombinowanych’ mają większe pole do popisu. W moim przypadku dysk SSD został przeznaczony tylko i wyłącznie na partycje systemowe (mam trzy, bo i potestować dystrybucje lubię). Pozostałe dane – a zatem katalog domowy /home, partycje z danymi, itp., z racji częstego kopiowania, przenoszenia, zapisywania lub kasowania na nich przeróżnych danych, zostały na dysku talerzowym (bo na taki komfort mogłem sobie pozwolić).

1. Ulokowanie dysku w maszynie i systemie

Obecne dyski SSD wyposażone są standardowo w interfejs SATAII lub SATAIII (zgodny w dół). Zatem podpięcie dysku do płyty głównej wymaga posiadanie takowego interfejsu, jak też zwrócenie uwagi w BIOSie, aby kontroler obsługiwał taki dysk w trybie AHCI. Instalacja Linuksa na takim dysku? Jeżeli ktoś nie ma jakiś dziwacznych problemów z kontrolerem (?), to po prostu dysk podpina, uruchamia instalator Linuksa i instaluje. Bez żadnej magii, tak po prostu. Jedyną rzeczą na którą należy zwrócić uwagę, to system plików jaki użyjemy na partycjach naszego dysku SSD. Aby wykorzystać specyfikę SSD z funkcją TRIM, powinniśmy użyć systemu plików który wspiera TRIM – zatem wybieramy pomiędzy standardowym Ext4, Btrfs, XFS lub GFS2. Ambitni mogą (a nawet powinni) zainteresować się wyrównaniem tworzonych partycji tak, by w pełni wykorzystały specyfikę dysków SSD.

2. Podstawowe podstawy – TRIM

Całe zamieszanie z funkcją TRIM w dyskach SSD wynika właśnie z potrzeby ograniczenia ilości zapisów na dysku, jak też polepszenie ogólnej wydajności podczas zapisu. Nie uwierzycie ile w dysku SSD jest ceregieli, aby zapisać dane do strony (na jakie podzielony jest nośnik, a które zgrupowane są w bloki). Panaceum na te zawiłości ma być TRIM w połączeniu z Garbage Collection. Zatem – w dobrym tonie leży korzystać z TRIM, ale jak? Pierwszy krok już uczyniliśmy – nasz system plików wspiera TRIM (Ext4, Btrfs, XFS, GFS2). Lecz domyślnie jego obsługa jest wyłączona. Wymagane jest poprawienie pliku /etc/fstab i dodanie odpowiednich parametrów przy naszej partycji dysku SSD. Dlatego najpierw wykonujemy kopię pliku fstab, a następnie otwieramy go do edycji:

sudo cp /etc/fstab /etc/fstab.bak
sudo gedit /etc/fstab

Odnajdujemy wpis naszej partycji (u mnie /) i przy opcjach dodajemy ‘noatime,discard’:

UUID=(...) / ext4 noatime,discard,errors=remount-ro 0 1

‘Discard’ włączy obsługę TRIM, ‘noatime’ poprawni nieco wydajność.

3. Usprawniania ciąg dalszy – Deadline w miejsce CFQ

Generalnie na włączeniu obsługi funkcji TRIM możemy zakończyć nasze zmagania z mediacjami pomiędzy Linuksem a Solid State Drive. Skoro jednak system pozwala nam na kolejne optymalizacje, dlaczego by więc z tego nie skorzystać. Pierwszym takim niuansem w przypadku dysków SSD pod Linuksem jest zarządca (scheduler) kolejkowania procesów I/O. Domyślnie Linux wykorzystuje CFQ, który jest zoptymalizowany pod zwykłe, talerzowe napędy. W przypadku SSD, który jest kawałkiem pamięci, najprościej mówiąc, nie ma konieczności wymyślnego kolejkowania danych, bo czas dostępu do wszystkich sektorów-stron pamięci jest taki sam. Dlatego zastosowanie najprostszego rozwiązania zwiększy dodatkowo wydajność SSD. A tym rozwiązaniem jest scheduler Deadline (lub Noop). Łatwo sprawdzimy, jaki zarządca jest obecnie w użyciu, wydając komendę (dla SSD pod sda):

sudo cat /sys/block/sda/queue/scheduler

A otrzymamy w rezultacie:

noop deadline [cfq]

Teraz musimy tylko pouczyć system, by dla dysku sda użył Deadline:

echo deadline > /sys/block/sda/queue/scheduler

Jak zrobić, aby działo się to samoczynnie przy starcie systemu? W przypadku Ubuntu 12.04 i przyszłego 12.10 oraz pochodnych (w tym Mint 13 i kolejny), Deadline jest już domyślnym zarządcą kolejkowania. W dystrybucjach, które nadal korzystają z CFQ, musimy odpowiednio spreparować plik /etc/rc.local, wklejąc na końcu (po wcześniejszym sudo gedit /etc/rc.local), zamieniając sda na nasz dysk:

echo deadline > /sys/block/sdX/queue/scheduler
exit 0

Nie wszędzie jest jednak tak łatwo i przyjemnie. Dystrybucje korzystające z nowego zarządcy usług systemd (Archlinux, Manjaro, itp), który nie bierze pod rozwagę /etc/rc.local, wymuszają na nas zmianę tego parametru na poziomie udev. Tworzymy zatem plik:

sudo gedit /etc/udev/rules.d/50-schedulers.rules

… i wklejamy:

# set deadline scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"

# set cfq scheduler for rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"

Ten sposób jest o tyle wygodny, że nie musimy w przyszłości pamiętać, że zmieniła się np. nazwa naszego dysku (z sda na sdb).

4. Korzystamy z SSD, ale nie korzystamy – swap, /tmp i inne

Wspomniany strach przed częstym zapisywaniem danych na naszym nowiutkim SSD ciągnie się ciągle za nami. Nieco podleczyliśmy tę fobie pozostawiając /home na dysku tradycyjnym. Jednak są miejsca w systemie, gdzie zapis jest przeprowadzany równie często co w naszym katalogu domowym, jak nie częściej. Takim miejscem jest… Nie, nie swap (o nim za chwilę), ale np. katalog /tmp. Skoro jednak dokupiliśmy do naszej konfiguracji sprzętowej dysk SSD, zatem przypuszczalnie mamy również zamontowane sporo pamięci. Dlaczego nie wykorzystać by jej na potrzeby plików tymczasowych? W ten sposób odciążymy SSD od częstego zapisu (w /tmp przewija się nasza codzienna działalność – i tak codziennie, od nowa). Ponownie zatem edytujemy plik /etc/fstab i wklejamy (o ile już takiej linijki tam nie ma – bo Archlinux i Manjaro na pewno ją posiadają).

tmpfs   /tmp       tmpfs   defaults,noatime,mode=1777   0  0

A co ze swapem? Ponownie – użytkownicy laptopów i urządzeń mobilnych nie mają wyjścia, jeżeli chcą używać hibernacji – swap musi być (co najmniej odpowiadający ilości zainstalowanej pamięci RAM) i to nawet na SSD (plusem jest, że hibernacja i powrót będzie sprawniejsza). Jeżeli natomiast mamy stacjonarny desktop i pamięci w okolicach 4GB i więcej – swap zapewne nigdy nie będzie u nas wykorzystany. Mamy zatem dwa rozwiązania – pominąć swap, albo ponownie wspomóc się dyskiem tradycyjnym lub pamięcią RAM (zram i swap w pamięci). Jeżeli jednak zdecydujemy się na swap na SSD, to by zminimalizować jego wykorzystanie możemy poinstruować system, by korzystał z niego w ostateczności. Wykorzystamy albo /etc/rc.local, albo /etc/sysctl.conf:

# rc.local, przed exit 0
echo 1 > /proc/sys/vm/swappiness

… lub:

# sysctl.conf, dopisujemy linijkę
vm.swappiness=1

A co z innymi katalogami systemowymi, gdzie coś często się dzieje? Można zastosować trick z tmpfs – np. /var/cache/apt/archives to tymczasowy katalog na pobierane pakiety aktualizacji. Dlaczego by nie miały wylądować chwilowo w pamięci? 

tmpfs /var/cache/apt/archives tmpfs defaults,noatime 0 0

5. Ostatnie maźnięcia po klawiaturze – journaling systemu plików

Gdy już tak majstrujemy przy systemie, warto przypomnieć sobie o starym tricku zwiększającym wydajność tradycyjnych dysków – mianowicie sposobie księgowania (journaling). Standardowo nasz system plików (np. ext4) na wypadek awarii bardzo skrupulatnie księguje wszelkie zmiany, co siłą rzeczy zmniejsza nieco wydajność operacji I/O. Ponadto taka asekuracja w przypadku dysków SSD zwiększa częstotliwość zapisu na nośniku – a tego nie lubimy. Aby całkiem nie pozbawiać się ochrony, przestawimy (zamiast wyłączyć) księgowanie na metodę writeback (metadane pliku), zamiast ordered (metadane pliku + dane). W tym celu musimy najpierw zmienić pewien parametr partycji:

sudo tune2fs -o journal_data_writeback /dev/sdXX

Gdzie sdXX to nasza partycji na dysku SSD, np. sda1.

Dalej jest nieco gorzej. Ponieważ na SSD mamy główny system plików, a w przypadku zmiany księgowania dodanie odpowiedniego parametru do /etc/fstab jest zwodnicze i niepewne, dlatego pouczymy od razu kernel jakim księgowaniem posługuje się partycja / (root). W tym celu edytujemy nasz /etc/default/grub (sudo gedit /etc/default/grub) i odnajdujemy linijkę GRUB_CMDLINE_LINUX_DEFAULT (to zapewni nam dodawanie parametru dla każdej partycji systemowej, także po aktualizacji), dodając na końcu jej parametrów rootflags=data=writeback:

# GRUB_CMDLINE_LINUX_DEFAULT ->  rootflags=data=writeback
GRUB_CMDLINE_LINUX_DEFAULT = "(...) rootflags=data=writeback"

… i wykonujemy sudo update-grub.

6. Mowa końcowa

Dla laika powyższe wywody wyglądają dramatycznie. Dlatego jak wspomniałem, zakończyć zabawę można już po włączeniu obsługi TRIM. A nawet i bez tego, dysk SSD będzie działał. Po prostu.

Dla oczekujących szybkich komend i błyskotliwych porad, powyższe nudziarstwo może być nie do przełknięcia – lecz różnorodność jaką stwarzają dystrybucje Linuksa wymaga paru słów szerszego opisu kontekstu i genezy działania.

Dla fachowców – temat został ledwie liźnięty.

Poza tym, sprawa jest rozwojowa – obsługa SSD zapewne za jakiś czas nieco się zmieni – nadejdą nowe technologie, rozwiązania w kernelu, poprawki w dystrybucjach, itp. Jedyne co nam pozostaje, to być świadomymi faktu, że zawsze jakoś nad technologią możemy spróbować zapanować.

PS. Równaj do megabajta

W związku z trafnymi uwagami w komentarzach, że pominąłem zupełnie kwestię wyrównania partycji, parę słów nt. co to takiego i dlaczego jest tak istotne dla żywotności i sprawności nośników SSD.

Temat wyrównywania partycji wynikł ze sposobu w jaki elektronika dysków SSD obsługuje dane. Otóż w tych napędach najmniejsza porcja informacji to strona (4KB), natomiast 128 takich stron tworzy blok (512KB) i to właśnie tutaj rozmiar ma znaczenie. Operacje kasowania/czyszczenia elektronika SSD potrafi przeprowadzać tylko angażując cały blok (czyli 512KB – Erase Block Size). Wyrównanie partycji polega na takim dobraniu ilości głowic i sektorów, aby cylindry (stara nomenklatura w służbie nowoczesnej technologii) szły ręka w rękę z porcjami danych, które przerabia SSD. Dlatego pilnujemy, aby nasze partycje zaczynały się od sektorów będących krotnością liczby 512 (przy czym pierwszy partycja powinna zawsze zaczynać min. od 1024 sektora – kwestia kompatybilności z MS-DOS). A co z głowicami, sektora i cylindrami? Domyślnie Linux produkuje partycje oparte o schemat 255 głowice i 63 sektory 512bajtowe (i to wszystko tworzy cylinder o pojemności 255*63*512). Zaleca się jednak stosowania geometrii 32 głowic i sektorów. Aby ją uzyskać, należy posiłkować się poleceniem fdisk i nim stworzyć partycje (gparted nie umożliwia określenia geometrii). Całość rozpoczniemy poleceniem:

sudo fdisk -H 32 -S 32 /dev/sdX

Jak sprawdzić, czy przynajmniej początki partycji mamy dobrze wyrównane?

sudo fdisk -l /dev/sdX

Urządzenie Rozruch   Początek      Koniec   Bloków   ID  System
/dev/sda1   *        2048    81922047    40960000   83  Linux
/dev/sda2        81922048   163841969    40959961   83  Linux
/dev/sda3       163842048   250068991    43113472   83  Linux

Wartości z kolumny ‘Początek’ powinny być podzielne przez 512 bez reszty. Niektóre porady jakie można spotkać, zalecają stosowanie wyrównania do bloków 128KB (geometria 244 głowic, 56 sektorów) – do tego należy jednak posiłkować się danymi producenta dysku SSD i rozmiarem stosowanego przez niego Erase Block Size.  

Tags:

38 komentarzy

  2. Pojęcia nie mam, to mój pierwszy dysk SSD. Zobaczymy, ile wytrzyma, choć producent daje 5 lat gwarancji. A wykorzystanie co najmniej funkcji TRIM jest zalecane wszem i wobec. Specyfika zapisu w przypadku pamięci flash robi swoje – mam doświadczenie z dwoma pendrive’ami, które już wyzionęły ducha a służyły mi może z dwa lata.

  3. Od prawie półtora roku siędzę na SSD (64 gigowy Vertex 2), leży na nim partycja systemowa i home. System używany głównie do deweloperki, więc jest na nim dość duży ruch. Po instalacji włączyłem tylko TRIM(i to tylko dlatego, że zwiększa on wydajność zapisu), zero problemów przez ten czas. Według mnie wyłączanie jurnalignu to jednak lekka przesada, dziś te dyski są na tyle dopracowane, że bez takich kombinacji powinny posłużyć przynajmniej tyle ile gwarancji daje producent. Do tego dość częsty backup i nie ma się czego obawiać 🙂

  4. Bardzo fajny wpis, generalnie, ale… 😉

    W kontekście Linuksa zabrakło paru słów o alignmencie partycji (4kB vs 512 bajty).

    Link do GFS2 na wiki jest nieprawidłowy (polska wersja istnieje, ale jest biedna – lepiej chyba podlinkować do angielskiej).

    Ostania uwaga: w kontekście tuningu swap warto rozważyć zram (opisałem: http://rozie.blox.pl/2011/11/Praca-na-destkopie-z-mala-iloscia-RAM-po-raz.html ). Dzięki wyższemu priorytetowi dane trafią na swap w zram, nie dotykając SSD, a system będzie szczęśliwy, że je wyswapował. Oczywiście ten trick nie uda się z hibernacją, ale to jakby nieistotne już.

  5. Dla obecnie produkowanych dysków SSD zamiast deadline lepiej wybrać noop.
    Zabawy z journalingiem można sobie też darować. Ewentualnie zwiększyć wartość commit. Dziś są to już zupełnie inne dyski niż kilka lat temu. Brakuje we wpisie wzmianki na temat cache przeglądarek. Opcja discard czasem spowalnia pracę lub powoduje problemy. Lepiej do tego użyć fstrim+cron.

  6. Czy wybór Noop zamiast Deadline jest konkretnie czymś podyktowany? Testy wydajnościowe Noop vs Deadline nie pokazują jakiejś wybitnej różnicy.

  7. Noop to najprostszy scheduler, generalnie przeznaczony dla pamięci flash. Gdy nie ma widocznej różnicy lepiej przy nim pozostać.
    Im prostsze narzędzie tym mniej problemów generuje. Dotyczy to większości nowszych SSD, w których są kapryśne kontrolery SandForce. Większość producentów (poza Samsungiem) z nich korzysta.
    Opcja discard (szczególnie przy dyskach Intela) też może powodować problemy. Lepiej użyć przeznaczonego do tego narzędzia: fstrim.
    Wyczytane na forach OCZ i Intela. Linków już nie znajdę, więc nie roszczę sobie praw do prawdy absolutnej 😉 Temat szybko się rozwija i zmienia. Najlepiej samemu poeksperymentować.

  8. Zastanawia mnie taka kombinacja: tradycyjny dysk SATA + Compact Flash w przelotce PCMCIA. Ma to sens?

  9. Szczerze powiedziawszy – chyba tylko w sytuacjach awaryjnych. Dobre osiąga zestawu przelotka + karta CF zależą od rodzaju karty (UDMA6?), rodzaju kontrolera obsługującego PCMCIA i jakości samej przelotki. Sumarycznie może się okazać, że koszt jest podobny, jak jakiegoś SSD 60 – 120GB (dobre karty kosztują), a prędkość i tak niewiele przebije osiągi zwykłego dysku na SATA.

  10. Dla dysków ssd najlepszy jest scheduler noop, nie każdy dysk ssd ma funkcję trim, warto to na początku sprawdzić z pomocą hdparm, reszta raczej okej.

  11. Ciekawy jestem, czemu jest napisane, że dla fachowców temat liźnięty, a do tego ledwie.

  12. art ogólnie fajny, dzięki. Ja jednak pracuję na zamrożonych systemach squashfs. Niestety – przyznaję – trzeba sobie z nimi nauczyc się sobie radzić. To nie prawda że te systemy nie działają. Trzeba tylko zrozumieć zasady w jaki spiosób następuje zapis. Ale po iluś tam próbach re we la cja. Pracuje się wyśmienicie. Co chcę to sobie dodaję, działają programy pod Windows, mam pełny system bez ograniczeń (no poza zapisem trwałym-zapisy odbywają się do pamięci). Jeżeli coś pcham do zapisu to mogę popchnąć via ssh. A jeśli coś dużego to korzystam z pliku overlay, później sobie to zamrażam i mam kapitalny system nie do zepsucia. Zapis dowolny od cd-rom poprzez USB aż po ssd.

  15. Witaj salvadhorze 🙂
    Czy wiesz w jaki sposób na linuksie mogę sprawdzić ile w sumie danych zostało zapisanych na dysku ssd od początku jego użytkowania?

    Pozdrawiam 🙂

  16. W Ubuntu/Mincie i wszystkim opartym o GNOME 3.x wystarczy uruchomić gnome-disks (trzeba mieć jeszcze zainstalowaną paczkę smartmontools). Jest tam sekcja informująca o zdrowiu nośnika.

    I teraz, trzeba tam wyśledzić :

    ID # 241 Total LBAs Written

    Represents the total size of all LBAs (Logical Block Address)
    required for all of the write requests sent to the SSD from the OS. To
    calculate the total size (in Bytes), multiply the raw value of this
    attribute by 512B. Alternatively, users may simply consult the Total
    Bytes Written indicator in Magician 4.0.

    I dzielimy to przez 512 – wynik to ilość wysłanych do dysku żądań zapisu w bajtach (dzielimy przez 1024*2 dla megabajtów).

    To teoria – bo nie mam akurat ssd pod ręką.

  17. Niestety ta metoda nie działa. Zainstaluję program I-NEX, może tam będzie taka opcja.

  19. Nie żebym matury z matematyki nie miał czy coś, ale … 😉

    Urządzenie Początek Koniec Sektory Rozmiar
    /dev/sda1 35197952 87633920 52435969 25G
    /dev/sda2 87634432 234441216 146806785 70G

    Kto poprawi? Rozmiar partycji mógłby zostać … (koniec dysku na 234441648)

    Z góry dziękuje!

  20. Czy zanim wkleimy do fstab-a linijkę

    “tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0”

    powinniśmy wcześniej wkleić linijkę z instrukcją rozpoczynającą się od kratki #….., tj. wg. schematu wcześniejszych wpisów w tym pliku, np.
    “# swap was on /dev/sda2 during installation
    UUID=97d2e556-4aa7-4e91-bb90-1bd9bdff5809 none swap sw 0 0”

  21. Ten poradnik to już ma trochę lat – od tego czasu większość narzędzi nauczyła się dokonywać optymalizacji SSD automatycznie (np. fdisk, gparted). Wyrównanie partycji na ssd można sprawdzić poleceniem:

    parted /dev/sda

    … i następnie polecenie:

    align-check optimal 1
    … a pożądany wynik to…

    1 aligned, gdzie 1 to numer partycji.

  22. Wszystko co zaczyna się od # jest komentarzem – zatem to tylko poprawi czytelność. Można przed tmpfs wstawić linijkę:

    # temporary folder

    .. czy coś w ten deseń.

  23. ok, dzięki.
    Mam jeszcze pytanie czy poniższy artykuł traktuje o tym samym (tworzenie ramdisków)?

    http://www.ubuntu-pomoc.org/tworzenie-ramdyskow/

    U mnie na Mint Xfce po komendzie $ di pojawiają takie wyniki

    Filesystem Mount Size Used Avail %Used fs Type
    /dev/sda1 / 27,4G 5,1G 20,8G 24% ext4
    /dev/sda3 /home 199,8G 36,7G 152,9G 23% ext4
    /dev/sdb1 /media/Dane 458,3G 206,9G 228,1G 50% ext4
    tmpfs /run 363,3M 1,3M 362,0M 0% tmpfs
    tmpfs /tmp 1,8G 0,0G 1,8G 0% tmpfs

    Czy z powyższego można odczytać, że katalog /tmp mam już przeniesiony do RAM-u?
    Czy może należy użyć innego polecenia?

  24. Ja katalogi /tmp, /var i /home trzymam na dysku talerzowym i linkuję je za pomocą dowiązań symbolicznych. Dysk SSD traktuję jako tylko do odczytu i trzymam na nim tylko system operacyjny i programy. Jedyna możliwość modyfikacji na dysku SSD to instalacja bądź usunięcie programu.

  25. Jak się ma Linux Mint 19 na SSD to trzeba coś samemu włączać i zmieniać ?
    System postawiony od nowa na SSD przez instalator z live DVD …

  26. Jaki system plików wybrać na dysku SSD ?

    Chcę zainstalować Linux Mint 19 i do wyboru mam EXT4 z księgowaniem , EXT3 z księgowanie, EXT2 i klika innych co ciekawe instalator systemu nie pokazuje innych opcji np. EXT4 bez księgowania ? Czy księgowanie jest złe a dysk do instalacji najlepiej przygotować samemu go formatując ?

  28. Dzięki ! Mam jeszcze jedno pytanie czy da się pod Linuxem włączyć overprovisioning ?
    Pod Windows 10 włączyłem to programem narzędziowym Cruciala tracąc ok. 10 % pojemności dysku 500 GB co mnie zbyt nie martwi bo mam jeszcze dodatkowo klasyczny magazyn HDD 1 TB. Czy pod Linuxem też to daje jakiś pozytywny efekt ? Czy można np. podpiąć na chwilę dysk z Linuxem pod Windows 10 , włączyć to i później korzystać z dobrodziejstw włączenia tego pod Linux Mint ? Czy działa to tylko dla dysków z systemem plików NTFS ?

  29. Niestety nie do mnie pytanie. Nie mam SSD 🙁 Sprawdź sobie overprovisioning+linux w necie i otrzymasz przynajmniej jakąś bazę informacji.

  30. Szkoda 🙁 Bo ekspertem w dziedzinie Linuxa to jesteś na pewno…Polecam zakupić SSD choćby do testów , teraz dysk Crucial 250 GB kosztuje coś ok. 279 zł. Postawiłem na nim wyłącznie system Linux , nawet swapa 4 GB . Dzięki poradnikowi uruchomiłem Trim , system plików EXT4 z księgowaniem i wszystko działa jak burza. Upgrade firmware dysku SSD zrobiłem podpinając na chwilę dysk pod system Windows 10 , live update przeszło bez problemów…W Windows 10 są dodatkowe opcje optymalizujące jego pracę a więc overprovisioning oraz momentum cache (wymagane 8 GB RAM). Pod Linuxem program narzędziowy Cruciala nie istnieje w związku z tym działanie tych dwóch opcji zależy wyłącznie od systemu.
    Teoretycznie overprovisioning da się włączyć i obsługiwać w Linuxie :
    https://www.thomas-krenn.com/en/wiki/SSD_Over-provisioning_using_hdparm
    Ale nie bardzo mi się chce zgłębiać ten temat , pod Windows 10 wystarczy wyklikać to programie i określić samemu wielkość o jaką zostanie zmiejszony dysk. Na dziś nie chce mi się “psuć” dysk , mam 5 lat gwarancji i chyba jakoś wytrzyma ? 😉 Ciekawy jest odczyt na SATA chyba wersja I ? wynosi on ok. 280 MB/sek. Gdyby podpiąć dysk do SATA III powinno być coś ok. 500 MB/sek. 🙂

  31. Czy ‚noatime,discard’: należy również dopisać przy swapie w fstab ? jeśli jest on na dysku SSD ?

  32. Żaden ekspert.
    Włączenie owego over-provisioning – wg tego co w linku – nie jest żadnym problemem.
    Przy okazji znalazłem coś takiego: https://www.leaseweb.com/labs/2013/07/5-crucial-optimizations-for-ssd-usage-in-ubuntu-linux/ oraz od Minta: https://sites.google.com/site/easylinuxtipsproject/ssd – może Ci się przyda.
    I drugie, które wydaje się być sensowne: http://www.leniwiec.org/2014/04/20/kilka-porad-dotyczących-użytkowania-dysków-ssd-w-ubuntu-linuxie/
    Wygląda też, że dla aktualizacji firmware’u nie jest konieczny Win10, czy cokolwiek ze stajni MS: http://www.storagereview.com/how_upgrade_crucial_ssd_firmware

    Jeśli chodzi o mnie i SSD… Cóż, od lat mam wyłącznie notebooka i… większe zaufanie do znanej od lat technologii HDD. Teraz na rynku pamięci nietalerzowych dzieje się sporo. Poczekam jeszcze. Mój rozsądek podpowiada mi, że najlepszym rozwiązaniem obecnie byłaby dla mnie hybryda SSD+HDD, przy czym nie chodzi mi o SHHD (czy jakoś tak) z np. 30GB SSD (lub alternatywą) i reszta na HDD. SSD na sam system – HDD na resztę (/home). Inna sprawa, że oprócz tego, że SSD znacząco szybciej działa (i – znów dla mnie: i co z tego?:)), to raczej większych zalet nie widzę.

    PS: Rozsądek (szczególnie innych) podpowiada, że mając system z dwoma dyskami (SSD i HDD) swap winien znajdować się na HDD. W ten sposób przedłużysz żywotność SSD, a i bez sensu nie zajmiesz jego pamięci. Inna sprawa, że SSD coraz trwalsze. Inna też sprawa, że 250GB wystarcza spokojnie na system i dane (+ ewentualny drugi dysk/chmura). Niemniej jednak, gdybym miał dwudyskowy system, to zrobiłbym tak: ok. 20GB na /, reszta SSD na /home, na HDD (jeśli podpięty na stałe) – swap (w dowolnej formie) + ew. magazyn danych podpięty gdzieś do /home. Można byłoby się również pobawić w wysłanie logów i całego tego badziewia, które – choć potrzebne – to niekonieczne zawsze do HDD również. Oczywiście tmpfs. Na HDD umieściłbym też jakiś alternatywny system (linux – nie używam innych), gdyby z pierwszym coś się podziało.
    Wydaje się, że SSD żyłoby się komfortowo, a całość niezbędnych rzeczy byłaby zachowana. Ba, przy takim układzie można nawet pomyśleć o backupowaniu danych z SSD na HDD.

  33. Dzięki za przydatne linki. Chyba faktycznie wyłączę swap i przeniosę go na klasyczny dysk HDD ? Co do aktualizacji fimware to producent udostępnia ją w formie pliku ISO z jakimś Linuxem który robi to automatycznie tylko należy najpierw te iso nagrać na nośnik i wykonać boot systemu z tego nośnika.

    Nie miałem wolnego pendrive a płytki szkoda na kilka sekund użycia 😉 prościej live update zrobić. Ja nie magazynuję danych na dysku SSD dlatego się nie boję ewentualnego posypania się całości.. U mnie układ obecny jest banalny prawie wszystko na / (czyli cały system + dane) i swap 4 GB na SSD.
    Cenne dane , zdjęcia magazynuję na klasycznym HDD. Nowy Linux Mint 19 ma fajną opcję przyrostowych migawek systemu coś ala przywracanie Windows , myślę że gdyby to zrobić automatyczne na HDD to można spać całkiem spokojnie ? 😉

  35. Mimo wszystko gorąco zalecam partycję /home. W razie potrzeby dobierzesz się do tego z dowolnego systemu.

  37. Przez te lata dzielnie wspierał stacjonarne pudło, jakiś czas temu trafił do laptopa w miejsce „talerzowca”. Obecnie działa tak jak i po zakupie – czyli bezproblemowo.

  1. Pingback: SSD |

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Post comment

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.