Új hozzászólás Aktív témák

• Fire/SOUL/CD félisten

  2014-04-21 11:18:45 #15174

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Fire/SOUL/CD

  félisten

  válasz Kendek üzenetére #15038

  "Na jó, de az fstrim nem ugyanaz mint a discard csatolási opció."
  Ha ezt valóban kijelentésnek szántad, akkor így van, azaz nem ugyanaz. Ha szánsz rá időt és 5-10x eljátszod ezt(mármint, amit írtál az fstrim-el script futása közben), akkor néha azt fogod tapasztalni, hogy nem történik meg a karbantartás(és az úgy is van "jól").
  Az fstrim (és egyéb hasonló cucc) utólag csak a nem használt blokkokat tudja karbantartani, a TRIM viszont valós-időben lap-szinten tart karban (1 lap 4KiB, 1 blokk meg változó számú lapból áll, mérete változó 256Kib-1Mib közt van általában). Ha egy fájlt törölnek, akkor olyan információk vesznek el, amik hiányában utólag csak blokk-szinten lehet karbantartani(ami pl 1 lap miatt is 256Kib-1MiB írást generál(hat)).

  Ez okozza azt a látszólagos anomáliát, amit fentebb írtam, mert ha a script által létrehozott temp állomány olyan blokkba (is) kerül, ahol más fájl(ok) "darabjai" is megtalálhatóak, akkor az már nem minősül "nem használt blokknak", ahhoz nem nyúlhat(és nem is nyúl) az fstrim. Az, hogy bizonyos idővel mégis karbantartásra kerül a blokk, az nem az fstrim érdeme, hanem az SSD-kbe beépített Garbage Collection funkcióé. (igazából az fstrim inkább Force Garbage Collection vagy egyes (Windows-os) Defrag-ok Consolidate Free Dsik Space funkciójára emlékeztet)

  Gyorsaság kérdése: Ezt igazából nem tudom hova tenni, mert nem tudom ki írta, meg milyen szempontból kellene értelmezni. Én 2 részre szedem a kérdést.

  1. Maga a Linux működése nem lesz gyorsabb vagy lassabb bekapcsolt discard opció mellett sem, mintha csak időközönként lenne futtatva az fstrim
  2. Ha fájlkezelőben törlök egy fájlt, annak a menetéből adódóan természetesen lényegesen lassabb, mint az fstrim, mert ez utóbbi csak "egy parancs", amit az SSD FW-e, vezérlője és NAND-jai hajtanak végre(a belső adatátvitel nem keverendő az OS-t az SSD-vel "összekötő" pl SATA portok sebességével) nagyon gyorsan. De ettől maga az OS megint nem lesz gyorsabb vagy lassabb...

  Windows XP/Vista nem támogatja a TRIM-t, azok alá szoktak Force GC opciós progikat tenni, amik időközönként elindulnak és a háttérben karbantartanak, de W7 vagy újabb esetén erre nincs szükség, mert a TRIM hatékonyan teszi a dolgát (Windows nem tesz különbséget HDD és SSD közt, a TRIM parancsot HDD esetén is küldi)

  Őszintén szólva én nem látok a Linux-ban semmi rációt a TRIM kezelésével kapcsolatban, nem találok semmi fejlesztői infót, hogy miért ezt az időzített/utólagos/több írást generáló megoldást preferálják...

Új hozzászólás Aktív témák