przystajnik

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.  

Post navigation

  • n3vr0s

    Jak myslisz ile dni / miesiecy stosujac te motody uda sie przedluzyc zywotnosc dysku?

  • 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.

  • Tomahawk

    Zapomniałeś o rzeczy właściwie najważniejszej związanej SSD. Mianowicie o wyrównaniu partycji (ang. alignment). Jeżeli mamy złe wyrównanie to zmniejszamy zarówno wydajność jak i żywotność dysku…

    Np. instalator Ubuntu „domyślnie” robi to dobrze, natomiast takiego arch-a już nie. Tak samo tworzenie tablicy partycji w gparted jest słabym pomysłem (domyślnie źle wyrównuje). Naprawdę warto sprawdzić czy ma się wszystko w porządku. Warto dodać też o tym informację do artykułu 😉

    Co do żywotności to już od jakiegoś czasu nie ma to praktycznie znaczenia. Ktoś przeliczał jaki musiałby być dzienny zapis (odczyt nie sprawia problemów) żeby zajechać dysk w ciągu 10 lat. Wartości były jakieś takie surrealistyczne, że szkoda gadać. A backup i tak zawsze trzeba mieć 😛

    Warto też wspomnieć w artykule o tym, że zanim zrobimy cokolwiek z SSD warto zaktualizować jego firmware. W niektórych przypadkach zwiększa to osiągi, w innych stabilność, a w jeszcze innych żywotność.

    A wpis ogólnie bardzo dobry. Pozdrawiam

  • majlo

    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ć 🙂

  • rozie

    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ż.

  • yossarian

    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.

  • salvadhor

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

  • yossarian

    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ć.

  • N

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

  • salvadhor

    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.

  • Czocher

    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.

  • tomtom

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

  • bio_jogurt

    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.

  • John

    Dysk /dev/sda1 nie zawiera poprawnej tablicy partycji

    Co dalej ?

  • nik

    /dev/sda <- bez '1'

  • Pingback: SSD |()

  • preter

    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 🙂

  • 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ą.

  • preter

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

  • preter

    Coś I-NEX nie chce się zainstalować, ale za to znalazłem ciekawą dyskusję: http://serverfault.com/questions/238033/measuring-total-bytes-written-under-linux

  • Profesor matematyki

    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!

  • Enzoo – zielony jak Mint

    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”

  • 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.

  • 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ń.

  • Enzoo – zielony jak Mint

    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?

Translate »