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

Aktualizacja microcode procesora w Debianie Wheezy – HOWTO.

Jakiś czas temu pisałem o 3 rzeczach, których zapewne nie aktualizujesz w Debianie (piszę w Debianie, ale zapewne prawdziwe jest dla większości dystrybucji opartych na nim). Jeśli chodzi o mikrokod, było prosto, łatwo, i przyjemnie. I minęło, wraz z nadejściem Wheezy’ego.

Magiczne polecenie update-intel-microcode, o którym wówczas pisałem, niestety nie jest już obecne w Debianie poczynając od wersji Wheezy. Zamiast tego, trzeba zrobić wszystko ręcznie. Nie wnikałem, ale zapewne chodziło o kwestie licencyjno-copyrightowe – przy pobieraniu pliku z mikrokodem ze strony Intela jest pytanie o zaakceptowanie licencji. W każdym razie nie ma już narzędzia i trzeba zadbać ręcznie o aktualizację mikrokodu.

Jest za to inne narzędzie, które – wraz z bazowymi mikrokodami – znajduje się w pakiecie intel-microcode.

Po pierwsze wchodzimy na stronę Intela, skąd możemy pobrać mikrokod. Wielkiego wyboru nie widzę, ale może się zmienić – wybieramy najnowszą wersję. Akceptujemy licencję, pobieramy plik. Na dysku ląduje plik o nazwie zbliżonej do microcode-20120606-v2.tgz. Należy go rozpakować, a naszym oczom ukaże się microcode.dat. To są mikrokody, których szukacie! 😉

Po drugie, przy pomocy narzędzia iucode_tool produkujemy z niego pliki w formie strawnej dla pozostałych narzędzi. Ja zdecydowałem się na rozpakowanie ich „na boczek”, żeby ręcznie porównać:

mkdir /tmp/ucode && iucode_tool -K/tmp/ucode/ /tmp/microcode.dat

Po tym zabiegu w katalogu /tmp/ucode mamy w tym momencie całkiem sporą ilość plików, które są gotowymi do użycia mikrokodami. Aby były używane, należy je skopiować do /lib/firmware/intel-ucode. Oczywiście jest możliwość rozpakowywania bezpośrednio w domyślną systemową lokalizację, wystarczy użyć przełącznika –overwrite i nie podawać katalogu docelowego.

Pora na użycie. I tu przyznaję zaczynają się schody. O ile wcześniej bez problemu można było załadować mikrokod online, to teraz iucode_tool -vk /tmp/ucode/* niby się wykonuje (wczytując wszystkie, czyli dla różnych procesorów mikrokody – zupełnie tego nie rozumiem), ale chyba nie działa. W każdym razie śladu w dmesg żadnego… Wygląda, że mikrokod jest dodawany do initramfs. Aby dodać mikrokody znajdujące się w domyślnej systemowej lokalizacji do wszystkich zainstalowanych kerneli, popełniamy:

update-initramfs -k all -uv

Po reboocie powinniśmy działać na nowym mikrokodzie. Uwaga: domyślnie do initramfs trafiają tylko mikrokody dla procesora, na którym jest wydawane polecenie. Można to zmienić w /etc/default/intel-microcode.

Dla procesorów AMD istnieje analogiczny pakiet, ale nie mam takiego pod ręką, by przetestować.

Przy pisaniu wpisu posiłkowałem się opisem Mikrokodu na wiki Arch. Co prawda niewiele się zgadza, ale może komuś się przyda. Warto też zajrzeć na ogłoszenie dotyczące mikrokodu, które znalazłem już po napisaniu wpisu.

 

Jak naprawiłem Libre Office 3.5.4 w Debianie.

Niedawno chciałem odczytać jakiś dokument w formacie .doc i okazało się, że Libre Office nie startuje. Pojawiała się plansza logowania i tyle. Potrzebowałem tylko odczytu, więc zwaliłem na Debiana w wersji unstable, locale ustawione na iso-8859-2, więc użyłem sąsiedniego kompa, skonwertowałem do PDF i zapomniałem o sprawie.

Jakiś czas później chciałem coś napisać, więc wróciłem do sprawy. Uruchomienie z wiersza poleceń, zmiana locale itp. nie pomogły. Jedyny komunikat, który dostałem, zawierał:

com::sun::star::uno::RuntimeException

Podejrzewałem Debiana unstable, więc szybkie sprawdzenie bugów i jest jeden #641412, w miarę pasujący opisem, ale niestety bez rozwiązania. Spróbowałem Google i tu efekt był lepszy. Znalazłem tę stronę [SOLVED] LibreOffice 3.5 error: Missing vcl resource. Tytuł optymistyczny.

Zainstalowałem pakiet libreoffice-gnome, tym razem przy uruchomieniu w oknie pojawiła się informacja o braku praw do pliku. Faktycznie, jeden z katalogów z plikami konfiguracyjnymi miał właściciela root. Usunąłem (z roota) ~/.config/libreoffice ~/.config/.libreoffice oraz ~/.config/.openoffice.org (ostatnia nazwa niedokładna), uruchomiłem Libre Office… Tadam!