• #106171 PROHARDVER!

  Új Válasz 2025-08-29 16:38:34 #106171

  Ú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

  

  PROHARDVER!

  (rögzített hozzászólás)

  Legyetek szívesek az offtopik témákat ne ebben a topikban tárgyaljátok ki. A topikgazda is jelezte, most törölni kellett jópár hozzászólást, most már maradjatok a (szakmai) topik keretei között.

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

• #92848 #75135488 törölt tag ubyegon2 #92844

  Új Válasz 2024-01-10 09:40:27 #92848

  Ú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

  

  #75135488

  törölt tag

  válasz ubyegon2 #92844 üzenetére

  Igen van értelme logikai meghajtón futtatni.

  Ahogy én tudom a dolgokat ... (tévedhetek)

  Egy ssd lemezvezérlő hardver (ata vagy nvme) honnét tudja melyik blokkokat lehet felszabadítani a TRIM vagy DEALLOCATE megoldásával?
  Mert ugye nem ismeri a tárhelyen lévő tartalmat.

  Onnét tudja, hogy megmondják neki.
  És itt jön képbe a discard és az fstrim.

  A discard fájlrendszer paraméter, ami annyit csinál, hogy minden "törlés-alapú" műveletnél (delete, move) a handler küldi a kérést és a paramétereket a lemezvezérlőhöz.
  Gyakorlatilag folyamatosan megy a TRIM vagy DEALLOCATE a hardveren.
  (Kivéve NTFS-3G használatkor, mert az nem küldözget, de a kernelben lévő ntfs viszont igen)

  Az fstrim egy program, ami végigjárja az adott fájlrendszert a handler segítségével és összegyűjti a felszabadítható területeket, ezek paramétereit átadja a lemezvezérlőnek és az ata-TRIM vagy nvme-DEALLOCATE megoldással elrendezi.
  (Ez működik az NTFS-3G-vel is, viszont nem működik a kernelben lévő ntfs-el)

  És itt jön a csavar ...

  Logikai meghajtó esetében van egy layer a fájlrendszer felett.
  Ez az én Luks-al kódolt lemezem esetében a DM-Crypt.
  A DM-Crypt hivatalosan nem javasolja a TRIM használatát, mivel adatszivárgáshoz vezethet. Ezt mindenki saját felelősségre használhatja.

  Mint fentebb írtam: "
  Encrypted partíció esetében némi adatszivárgást jelent amúgy, de nálam ennyi belefér"

  Gyakorlatilag az "allow-discard" paraméterrel mondom meg a dm-crypt-nek a grub-ban, hogy amikor induláskor feloldja a lemezt, akkor fogadjon el a fájlrendszert alkalmanként végignéző fstrim-től ilyen kéréseket és ezeket továbbítsa a lemezvezérlőhöz.
  (Hogy ez az alkalom cron alapú [fstrim.timer] vagy kézi indítású egyéni meglátás kérdése.
  Mivel esetemben ez adatszivárgással jár, én kézzel futtatok néha, ha épp eszembe jut.)
  Az fstab-ban nem adtam meg a /dev/mapper/root eszköz ext4 mounthoz "discard" opciót, így a folyamatos "TRIM" nem megy.

  Amúgy szerintem a fejekben azért van sokszor kavar, mert tudomásom szerint a TRIM szabvány anno ererdetileg leírta a protokol szoftveres (OS-en történő) és az eszköz (S-ATA) hardveres megvalósítását is. Viszont ekkor még nem volt értelmezve nvme, sas, usb és egyéb logikai eszközökre.
  Utóbbiaknál változott a hardveres implementáció, de OS-oldalról csak egy kiterjesztés történt. Ezért kb. OS-felől minden ilyesmi TRIM-nek látszik, de hardver oldalról már nem.

  Amúgy egy táblázat a discard, fstrim linux oldalról történő alkalmazásáról különböző fájlrendszereken: [link]

  A dm-crypt megoldás discard elfogadáshoz és a figyelmeztetés: [link]

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