Bari Wiki

Uživatelské nástroje

Nástroje pro tento web

Historie:
todo

Toto je starší verze dokumentu!

Obsah

TODO

Přechod na SSD

Analýza

  • M2 960 EVO 250 GB nebo SATA 850 EVO 500 GB
    • M2 je mnohem rychlejší, hlavně v benchmarcich, ale prakticky je to prý dost podobné, protože SATA je už dostatečně rychlá
    • M2 teď stojí 3600, SATA 4500. Za +900 bych měl 2x větší uložiště
    • M2 se prý celkem hřeje
    • M2 používá protokol NVMe, který obchází například IO scheduler v Kernel
  • chci mit rootfs cely na SSD a na velka data + backup HDD raid
    • celý můj linux má tak 35 GB, nejvíc dat má XPL, fotky/videa, virtuály, hry …
      • 850 GB home
        • 243 GB (k archivaci) shared (fotky, videa)
        • 576 GB djbuldog
          • 294 GB (k archivaci) zaloha XPL
          • 77 GB VMs
          • 75 GB steam
          • 62 GB projekty
          • 20 GB diabloIII
          • 14 GB prace
          • 8 GB (k archivaci) skola
          • 8 GB (k archivaci) zaloha
          • 18 GB zbytek
        • 31 GB goja
      • 115 GB opt
        • 70 GB XPL11
        • 43 GB (k archivaci) XPL10
      • 25 GB zbytek
      • na SSD mi vychází nějakých 392 GB co bych tam chtěl mít, zbytek 596 GB jsou zálohy :D
    • na současných discích udělám 250/500 GB partition md2 raid1 pro zálohu rootfs přes rsync
    • NTFS paritions zruším
    • efi partition na obou nechám
    • na md2 nahraji rootfs (kromě dat k archivaci)
    • nabootuji z md2, když ok…. vymažu z md1 systém, udělám z toho mount point /mnt/data

Ǔprava HDD disků

  • přes gparted jsem odstranil NTFS oddíly
  • raid oddíl ale nešel vytvořit, tak jsem použil gdisk
    • na obou discích jsem vytvořil 500GB oddíl na stejných sektorech
    • zůstala mezera cca 67 GB mezi původním raid a novým
      • schválně jsem tu mezeru dal za md1 a před md2, aby šel md1 v případě potřeby jednoduše roztáhnout až k md2
    • s původním raid jsem nic nedělal, ale je zde možnost růstu
    • za oddílem je 100 MB pro EFI
  • oprava zavaděče systému
    • příkazem update-grub po chroot (viz raid) na md2 jsem vygeneroval nový grub.cfg
    • bylo potřeba ale vygenerovat i nový EFI přes grub-instal /dev/sdXY
  • mount / jako RO
    • před kopírováním dat jsem chtěl rootfs připojit readonly
    • postupoval jsem podle raid, ale přechod na init1 nestačil pro uvolnění /
    • použil jsem boot do single user režimu
    • / nejde připojit do jiného adresáře (ani read-only), pokud je už připojen RW někde
    • pro přechody z RW na RO (a naopak) jsem použil mount -o ro,remount /
  • rsync
    • pro přenosy souborů jsem používal rsync
    • několikrát se mi stalo, že se mi nějak nesychronizovala všechna data
    • jednou za to mohlo použití ADRESAR/* jako source, místo jen ADRESAR/
      • hvězdička totiž vynechává soubory/adresáře začínající tečkou
    • jednou z toho podezřívám reset systému bez umount (a následný repair fs)
    • dvakrát se mi to stalo z nepochopitelných důvodů. Raději jsem pak vždycky provedl umount, reboot a znovu rsync.. pro kontrolu :)
    • důležité parametry
      • -a zachovat atributy a oprávnění
      • -c implicitně se soubory porovnávají podle mtime + size, parametr c vynutí pomalejší ale důkladnější checksum
      • -v verbose režim, aby bylo jasné co to dělá :)
      • -n velice užitečný parametry, který simuluje synchronizaci bez vlastního kopírování/mazání dat (dry-run)
      • –delete odstraní soubory, které nemají být v dest
      • –exclude vynechá zadané adresáře/soubory
rsync -avn --exclude /home/djbuldog/Downloads --exclude /home/djbuldog/skola --exclude /home/djbuldog/zaloha --exclude /home/djbuldog/adva --exclude /opt/X-Plane\ 10 --exclude /opt/X-Plane\ 11 --exclude /home/shared /dev/shm/old/ /dev/shm/new/
rsync --delete -avn --exclude /home/djbuldog/Downloads --exclude /home/djbuldog/skola --exclude /home/djbuldog/zaloha --exclude /home/djbuldog/adva --exclude /home/shared /dev/shm/old/.oldroot/ /dev/shm/new/

Úpravy SSD disku

  • zarovnání oddílu
    • pokud nemáme partition tabulku, tak není třeba vůbec řešit zarovnání
    • pokud ano, tak chceme mít parirtion zarovnané na celé fyzické bloky se kterými zařízení umí pracovat
    • běžné HDD mají fyzické bloky typicky 512 B nebo 4 kiB
    • u SSD se rozlišuje
      • page size - minimální velikost, kterou lze číst/psát, typicky 8 kiB
      • block / erase block / erase block size (EBS) - minimální velikost, kterou lze vymazat, typicky 512-2048 kiB
    • můj Samsung 850 EVO je typu TLC, pravděpodobně má page size 8 kiB a erase block 3×512 kiB. Někde jsem ale četl, že má erase block možná 2048 kiB. Z toho důvodu jsem nakonec raději zvolil zarovnání na 6 MiB (minimální společný násobek)
    • protože mám tabulku GPT, použil jsem na zarovnání nástroj gdisk
      • počítá s velikostí sektoru 512 B a oddíly zarovnává na násobky 2048 sektorů
      • zadáním x lze přejít to expertního režimu, ve kterém lze zadáním l nastavit novou hodnotu počtu sektorů, na kterou se budou oddíly zarovnávat
      • pro zarovnání na 6 MiB to vychází na 12288 sektorů (6*1024*1024/512)
      • následně jsem zadáním n vytvořil oddíl pro rootfs a EFI partition (pouze 6 MiB)
        • EFI parition jsem dal až za rootfs, aby se dala jednoduše změnit její velikost, případně zrušit
      • správné zarovnání lze ověřit zadáním v
    • fdisk/linux prý pořád používá počet hlav x sektoru na stopu = cylinder (v sektorech). V těchto nástrojích se musí zadat počet hlav a sektorů na stopu pro nastavení zarovnání. Například pro erase bloky 512 kiB se doporučuje 224h x 56 sektorů nebo 32h x 32s
  • vytvoření rootfs
    • použil jsem ext4
    • filesystém prý používá bloky o velikosti 4 kiB
      • ideální by bylo použít stejnou velikost jako u zarovnání, plýtvalo by se ale hodně místem
      • každopádně, 8 kiB a 512-2048 MiB je alespoň násobkem 4kB
    • často se doporučuje nastavit ještě parametry stride a stripe-width
      • jsou určeny pro raid, ale hodí se i pro SSD
      • stride
        • This is the number of blocks read or written to disk before moving to the next disk - the chunk size.
        • Interpretation: this is the smallest amount of data the filesystem will use to copy/read data from one disk,
      • stripe-width
        • This allows the block allocator to prevent read-modify-write of the parity in a RAID stripe if possible when the data is written.
        • Interpretation: the filesystem will try to arrange writes in blocks of this size in order to minimize expensive operations. In RAID configurations using parity (like RAID 5) read-modify-write operations are expensive because the original data and parity are read, the data is modified, the new parity is recalculated and then the new data and the new parity are written back to disk.
      • mělo by se nastavit jako
        • stride = X / 4 kB, kde X je page size SSD disku
        • stripe-width = X kB / 4 kB, kde X je erase block SSD disku
      • jelikož jsem si ale nebyl jistý s velikostí EBS na mém disku, raději jsem parametry nenastavoval
  • data jsem na SSD nakopíroval přes rsync (viz úpravy HDD)

Optimalizace

TRIM

  • nový ATA příkaz zavedený kvůli SSD, kterým OS informuje řadič disku, které bloky jsou považovány za prázdné
  • existují dvě verze
    • non-queued TRIM
      • starší, blokující.
      • problém je, že volání po každém delete velice zpomaluje výkon disku.
      • provádí se proto periodicky jednou za čas. V linuxu přes fstrim -av v cron.
    • queued TRIM
      • nečeká se na provedení
      • u ext4 se zapíná klíčovým slovem discard při mount
  • Samsung EVO 850 podporuje obě verze, ale…
    • funguje ale jen verze non-queued, protože druhá je špatně implementována.
    • v kernel je „Samsung 8*“ na blacklistu ata6.00: disabling queued TRIM support
  • automatické spouštění trim
    • přes systemd Realtime timer
    • obsahuje parametr Persistent=true - spustit při aktivaci, pokud se propáslo poslední spuštění
cp /usr/share/doc/util-linux/examples/fstrim.{service,timer} /etc/systemd/system
systemctl enable fstrim.timer
  • upravil jsem časování z jednou týdně v pondělí 00:00 na jednou týdně v neděli v 22:00
#OnCalendar=weekly
OnCalendar=Sun, 22:00
systemctl start fstrim.timer
systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
   Loaded: loaded (/etc/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
   Active: active (waiting) since Sun 2017-12-03 10:17:21 CET; 12min ago
  Trigger: Sun 2017-12-03 22:00:00 CET; 11h left
     Docs: man:fstrim
systemctl list-timers fstrim*
NEXT                         LEFT     LAST                         PASSED    UNIT         ACTIVATES
Sun 2017-12-03 22:00:00 CET  11h left Sun 2017-12-03 10:17:21 CET  17min ago fstrim.timer fstrim.service

mount

  • při mount / na SSD používám noatime
  • /tmp je dobré připojit do tmpfs místo SSD. U systemd k tomu je služba (jde ale i přes fstab)
cp /usr/share/systemd/tmp.mount /etc/systemd/system/
systemctl enable tmp.mount

webový prohlížeč

  • spouštění profilu prohlížeče v RAM
#apt-get install profile-sync-daemon
$psd
First time running psd so please edit /home/djbuldog/.config/psd/psd.conf to your liking and run again.
  • v konfiguraci se nastaví jaké prohlížeče se používají, jaké profily má strkat do ram
  • následně se spustí uživatelská služba přes systemd
systemctl --user start psd-resync
  • stav lze sledovat přes
psd preview
Profile-sync-daemon v6.31 on Debian GNU/Linux buster/sid

 Systemd service is currently active.
 Systemd resync-timer is currently active.
 Overlayfs technology is currently inactive.

Psd will manage the following per /home/djbuldog/.config/psd/.psd.conf:

 browser/psname:  chromium/chromium
 owner/group id:  djbuldog/1000
 sync target:     /home/djbuldog/.config/chromium
 tmpfs dir:       /run/user/1000/djbuldog-chromium
 profile size:    14M
 recovery dirs:   none

 browser/psname:  firefox/firefox
 owner/group id:  djbuldog/1000
 sync target:     /home/djbuldog/.mozilla/firefox/9wxm9t35.default
 tmpfs dir:       /run/user/1000/djbuldog-firefox-9wxm9t35.default
 profile size:    154M
 recovery dirs:   none
  • profil se synchronizuje každou hodinu
djbuldog@Pharaon:~$ systemctl --user list-timers
NEXT                         LEFT       LAST PASSED UNIT             ACTIVATES
Sun 2017-12-03 12:24:24 CET  56min left n/a  n/a    psd-resync.timer psd-resync.service
  • profil neobsahuje cache prohlížeče!!
lsof | grep firefox | grep -v /usr/lib
..
86 20975455 /home/djbuldog/.cache/mozilla/firefox/9wxm9t35.default/startupCache/scriptCache-child-current.bin
..
  • přemístění cache
    • mělo by se dělat přes about:config, ale moc mi to nefunguje
      • zobrazit jen „browser.cache“
      • browser.cache.disk.enable nastavit na false
      • browser.cache.memory.enable nastavit na true
      • browser.cache.memory.capacity přidat a nastavit na třeba 358400
    • ale nějak to nepomohlo, prohlížeš pořád leze do ~/.cache/mozilla/firefox

uspávání HDD

  • příkazy posílám přes hdparm
  • parametrem -S 12 nastavuji standby režim po po 1 minutě neaktivity, což plotny úplně zastaví
  • alternativně lze parametrem -y nastavit rovnou standby režim
  • existuje ještě parametr -Y, který disk přepne do hlubšího sleep režimu
    • ten ale na mých HDD nefunguje dobře a disky se často probouzí
    • probudí je například i dotaz na stav disku parametrem -C
    • aby se ze sleep neprobouzeli, musel jsem
      • odpojit partition (spouštěla se například indexace souborů updatedb)
      • deaktivovat sw raid
      • vypnout SMART daemono
      • vypnout službu udisks2 (zajišťuje připojování svazků)
  • standby funguje tedy podle očekávání, má jenom jednu mouchu
    • při vypínání/uspávání se disky nejprve probudí ze standby, aby se mohly vypnout :)
  • v gnome3 jde nastavit přes gnome-disks
  • zobrazí se seznam disků, označit disk, přes menu v pravém rohu vybrat „nastavení disku“
  • zapnutí standby se uloží do souboru s ID disku do složky /etc/udisks2/
cat /etc/udisks2/ST2000DM001-1CH164-Z1E3S9LW.conf 
# See udisks(8) for the format of this file.

[ATA]
StandbyTimeout=12

zapnutí raid bitmapy

  • u SW raid md2 se mi vytvořila automaticky
  • u md1 jsem ji neměl
  • bitmapa slouží k rychlejší obnově desynchronizovaného pole, což se fakt hodí :)
  • může to mít lehký vliv na zapisovací výkon, ale to mě moc netrápí
  • lze kdykoliv zase vypnout, zapnutí provedeno přes
mdadm --grow --bitmap=internal /dev/md1

IO scheduler

cat /etc/udev/rules.d/60-ssd-scheduler.rules
# set deadline scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"
  • ověření
for f in /sys/block/sd?/queue/scheduler; do printf "$f is "; cat $f; done
/sys/block/sda/queue/scheduler is noop [cfq] 
/sys/block/sdb/queue/scheduler is noop [cfq] 
/sys/block/sdc/queue/scheduler is noop [cfq]
..

TODO

FIXME

  • zbývající z https://wiki.debian.org/SSDOptimization (případně další weby)
    • co ten goanysync?
      • nepoužít jej na vyřešení toho problému s .cache/mozilla/firefox? nebo /var/log? když se tato data ztratí, tak se nic neděje. Jejich zapisování ale zbytečně žere SSD
      • otázkou je, zda bych pak neměl přestat používat ten psd.. ať jich nemám milión
  • pravidelná synchornizace / na md2
    • normálně přes rsync nad RW /, chce to jen vynechat /tmp, /proc, /sys, /dev …
    • chtělo byt o nějaká základní kontroly, jako jsou svazky fakt připojený do mountpoint?
    • mohl bych z toho udělat systémovou nebo user službu :)
  • neprobouzet disk pri suspend/resume
    • před suspend se disk probudí a hned usne znovu
    • nějak by to jít mělo, ne?
    • HDD má prý životnost cca 200 000 start/stop (já mám teď nalítáno cca 4k)
    • pm-suspend log píše něco o /usr/lib/pm-utils/sleep.d/95hdparm-apm
    • který importuje /lib/hdparm/hdparm-functions
    • který parsuje /etc/hdparm.conf
    • místo /dev/sdX by mělo jít použít i /dev/disk/by-id/ata-ST2000DM001-1CH164_Z1E3S9LW
    • mohl bych se pak vykašlat na ten gnome-disks (udisks2)
    • custom skripty strk8m do /etc/pm/*
    • já myslím, že za to zapnutí disku před suspend může zavolání sync :( s tím nic neudělám

Hodnocení

  • start Linuxu se zrychlil
    • grub naskočí o dost rychleji
    • pak startuje jádro, to je úplně stejně rychlé.. pár sekund
    • pak se spustí init, systemd… ten je znatelně o dost rychlejší
  • přihlášení je rychlé
    • zhruba stejně, jako když jsem předtím dal logout a login (diskcache v RAM)
  • předtím jsem schválně uspával stroj, abych to měl svižnější… teď ten reboot vůbec nebolí
  • spuštění prohlížeče je stejně rychlé jak jsem zvyklý (disková cache)..,
  • takže pozitiva jsou rychlejší start, první spuštění programů a možnost vypínat hlučné HDD

zbavit se reklam v TV

streamování zvuku přes síť

todo.1516824005.txt.gz · Poslední úprava: (upraveno mimo DokuWiki)
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki