Pamięci flash, czyli pendrive, microSD itd.

Czasem człowiekowi wydaje się, że coś wie i… no właśnie, wydaje się. Że są różne pendrive’y (czy tam ogólnie pamięci flash), to wiedziałem. Wiedziałem też, że mają klasy i poszczególne klasy odpowiadają różnym prędkościom zapisu. I tyle.

Niedawno od hrw dowiedziałem się, że to nie do końca tak, że parametrów jest znacznie więcej i że w praktyce mają one spore znaczenie przy stosowaniu karty jako nośnika dla systemu Linux. Bo jednak czym innym jest zapis filmu na FAT, a czym innym realne operacje na jakichś linuksowych systemach plików.

Ostatnio uruchomiłem grzejnik na starym pendrive, użyłem ext2 i zdarzyło mi się trochę ponarzekać na μblogu, że wolno działa i w ogóle. Dostałem odpowiedź, że minimalny cluster size dla nośnika flash powinien być 4k. Co przypomniało mi wcześniejszą rozmowę i skłoniło do zadania pytania jak sprawdzić cluster size? Co dość szybko przywiodło mnie do wpisu nt. optymalizacji systemu plików dla pamięci flash.

Zauważyłem, że blog do którego powyżej linkuję ma raptem trzy wpisy i to sprzed roku, więc ryzyko zniknięcia jest spore. Pozwolę sobie zacytować dla pamięci część dotyczącą analizy:

  1. Interesting parts of this result are the diff changes drastically at two places:
    1. from  8388608 (8Mb) to 4194304 (4MB): Based in example readme in flashbench, this indicates that there was no performance overhead reading two blocks over the 4mb boundary, but there was for 8mb boundary. The guess is then that the erasure block is 8mb large on my sd-card
    2. before 8192 and after. I would really like to know why there is a bump at 8k, but times after that are so much lower, so 8k is obviously some sort of boundary point.
  2. From this, I deduce two things,
    1. Ext4 should have a block size of 4k, and the “stride” value should be 2. This will cause ext4 to think that units of 2 blocks (8k) can and should be treated as one.
    2. Ext4 should have the stripe-size set to 1024. This value was calculated by taking 8M (guessed erasure block size) dividing by 8K (size of a stride, 2 times block size (4K)). This will (hopefully) cause Ext4 to try to align writes so that while erasure blocks are written continuously and make it avoid sub-block updates.

Część dotyczącą ustawiania początku partycji w fdisk:

First sector (2048-15759359, default 2048): 16384

Wraz z wyjaśnieniem, skąd to się wzięło:

Fdisk uses blocks of 512 bytes, so that means that we want to start at 8*1024^2/512 = 16384.

No i na koniec część dotycząca tworzenia samego filesystemu ext4:

Reformat the filesystem, this time with Ext4 with block size of 4k, without journaling, but with additional parameters to encourage Ext4 to do the right thing with respect to the erasure block:

mkfs.ext4 -O ^has_journal -E stride=2,stripe-width=1024 -b 4096 -L Fedora14Arm  /dev/mmcblk0p1

Na koniec dwa linki, które autor wpisu podaje jako źródła:

Zachęcam do lektury całego wpisu z którego pochodzą powyższe cytaty, bo powyżej są jedynie najważniejsze wyjątki, które bez kontekstu nie do końca w czymkolwiek pomogą.

Inny, prostszy (ale starszy) wpis o podobnej tematyce: http://linux-howto-guide.blogspot.com/2009/10/increase-usb-flash-drive-write-speed.html

No i dowiedziałem się, że pożyteczne narzędzie to flashbench (pakiet jest w Debianie unstable), że żaden ext2 dla nośników flash, tylko ext4 bez journala, za to z dodatkowymi opcjami, zależnymi od parametrów karty. I że nie tylko w przypadku SSD warto stosować alignment. Różnica prędkości między ext2 a ext4 po tuningu? Wg autora wpisu 8 razy szybciej dla małych plików i dwa szybciej dla dużych. Trochę mi wszystko opadło, ale za to wiem, co będę robić w weekend.

UPDATE: Trochę się pobawiłem i wyszło mi, że metoda pomiaru jest średnio dokładna. Albo pendrive zwalnia w miarę używania (w sensie „wykonana ilość zapisów”), albo reboot/hibernacja drastycznie zmieniają wyniki, albo nie wiem co jest grane. Bo zrobiłem test na FAT, potem na ext4 po dopasowaniu partycji (brak zauważalnych różnic), potem zabawa z ustawieniami ext4 i… między pierwszym testem na ext4, a końcowym, na identycznych parametrach ext4 były 4 sekundy różnicy. Przy podstawie 22 sekundy, więc prawie 20% wolniej. Zagadka. A ponieważ nie widzę zysku między FAT a ext4, to chęć do migracji ext2 -> ext4 gwałtownie spadła. Może kiedyś.

UPDATE2: Dodane cytaty z bloga. Bawiłem się trochę w optymalizacje/benchmarki na czterech różnych pendrive’ach. Tylko jeden zareagował pozytywnie na zmianę alignmentu (OK, bez wyliczeń było, po prostu początek partycji na sektorze 16384) i zmianę systemu na ext4. Przy okazji wyszło na jaw, że pendrive, który uznałem za wolny jest ok. 3 razy wolniejszy od pozostałych, niezależnie od ustawień.

Wyciszanie grzejnika.

Pod koniec zeszłego roku komputer robiący za grzejnik przestał działać. Padł dysk. Software RAID na dwóch partycjach niewiele pomógł. Tzn. pomógł na tyle, że były sygnały, że wkrótce się skończy. Gdybym miał jakieś ważniejsze dane, to zapewne zdążyłbym zgrać. Inna sprawa, że wg statystyk zrobionych przez Google, IIRC 30% dysków nie ma żadnych, ale to naprawdę żadnych objawów w S.M.A.R.T, zanim padną. Jakby komuś bardzo zależało i nie mógł znaleźć – dajcie znać w komentarzach, to poszukam tych statystyk Dzięki GDR! za podesłanie linka!

Wracając do tematu. Wymieniłem komputer w domu u rodziców, przełożyłem ze starego dysk do nowego. Zapomniałem o tym, włączyłem go i… praktycznie totalna cisza. Mimo w sumie trzech wentylatorów (zasilacz, radiator na procesorze i wentylator jak od zasilacza puszczony na 5V chłodzący kartę graficzną). Okazało się, że głównym hałasującym był dysk (Seagate 60 GB).

To podsunęło mi pomysł, żeby spróbować tego samego z grzejnikiem. W końcu komputer uruchamiający się z pendrive był ćwiczony wielokrotnie. Może nie w tak hardcore’owej wersji, bo jednak zawsze na podorędziu był dysk wpięty po USB, ale to przecież drobiazg. Przy okazji nauczyłem się patentu: jeśli komputer nie ma bootowania z USB w BIOSie, albo ma takie, że nie potrafi zabootować się z pendrive’a, to można zabootować z CD-ROM i kazać bootować z USB. Wymaga co prawda sprawnego napędu CD-ROM, ale działa. 🙂

Dzisiaj przywiozłem grzejnik. System zainstalowany na pendrive, póki co bez tuningu pod kątem trwałości tego ostatniego. Znaczy jest ext2, nie ma swap, ale reszty opcji nie miałem kiedy włączyć. Oczywiście tym razem nie będzie dysku tylko do odczytu, bo mprime musi gdzieś zapisywać wyniki (BTW przechodzę wyłącznie na wstępną faktoryzację – w jeden sezon grzewczy i tak nie jestem w stanie „konkursowej” liczby przeliczyć), ale to nie powód, by katować flasha ponad potrzebę.

Pamiętałem, że wentylatory w tej maszynie dość szumią, więc przypomniał mi się zacny wpis z Majsterkowo.pl o naprawie głośnych wentylatorów. Co prawda wyciąganie zawleczki i wyciąganie ośki uważam za overkill, ale rozebrałem i wentylator od procesora, i ten w zasilaczu i przesmarowałem sprawdzonym sposobem (kropelka oleju maszynowego). Jest o niebo lepiej, choć nadal troszkę go słychać. Winny jest badziewny radiator i wentylator zamontowany na nim, który jakby ma lekkie bicie. I w ogóle trochę mały jest ten radiator, i mniejszy niż w zasilaczu ma wentylator. Trochę żałuję, że nie przełożyłem z mojego starego domowego komputera procesora (Athlon 2200+) – obecnie jest Sempron 2300+, czyli słabszy. No i oczywiście radiatora (tego z niesłyszalnym praktycznie wentylatorem). Przy okazji mogłem też wymienić wentylator w zasilaczu, choćby na ten, który dmuchał na grafikę w starym komputerze. No ale nie było czasu… ;-/

Przy okazji otwierania zasilacza w celu przesmarowania i wyczyszczenia wentylatora znalazłem spore pokłady kurzu. Niestety, okazuje się, że samo odkurzenie zasilacza przez szczeliny nie pomaga, a sprężonego powietrza nie miałem nigdy pod ręką. Dodatkowo wyszło na jaw, że jeden z kondensatorów trochę wyciekł. Mam już lutownicę, ale nie miałem kondensatora na wymianę. Póki co działa, więc nie ruszam. Mam nadzieję, że nie odparuje razem z płytą…

UPDATE: Note for myself: w tym roku dniem uruchomienia grzejnika jest 02.12.2012. I nie jest to początek sezonu grzewczego.

UPDATE2: Może i było lepiej przez chwilę, ale dość szybko się pogorszyło. Tym razem pamiętałem i wyjąłem wentylator z nieużywanego komputera. Okazuje się, że nie był na 5V, a i tak był praktycznie niesłyszalny. Jakiś Arctic, które kupiłem za grosze w większej ilości wieki temu. Co prawda z mocowaniem był cyrk, bo żeby wkręcić cztery wkręty brakuje jakichś 5 mm na długości radiatora, ale dało się zamocować na dwóch (skombinowanych z kołków, bo wentylator różni się głównie wysokością, więc oryginalne nie pasowały). 1700 RPM w tej chwili i cisza – ten z zasilacza jest głośniejszy.

Root tylko do odczytu (flash).

Trochę czasu minęło, odkąd pisałem o kluczu USB jako partycji root i tylko do odczytu. Oczywiście, jak się spodziewałem, nie wyczerpałem tematu i parę rzeczy wyszło w praniu.

Pierwsze – i w sumie najważniejsze – co wyszło – po przemontowaniu / w RW, instalacji nowych pakietów – nie daje się przemonotować w RO. Winnych było dwóch – blkid.tab oraz usunięte pliki nadal używane przez proces.

Szczęśliwie w trakcie poszukiwań rozwiązania wpadłem na ReadonlyRoot na Debian Wiki, gdzie opisane jest, co zrobić. W przypadku blkid.tab należy zrobić symlinka i ustawić zmienną środowiskową. W przypadku używania usuniętych plików – zrestartować odpowiednie serwisy (polecenie checkrestart z pakietu debian-goodies). Poza tym, skorzystałem z patentu na mtab.

Na koniec potwierdzenie pierwszego spostrzeżenia – jest stabilnie. Bez UPSa 14 dni było.