magnatIgen is, meg nem is. Ha nemrég futott le a cronbeli szkript, és nem volt írás/törlés, akkor elvileg lehetséges, és jó is, hogy nulla bájtot trimmelt (ugyebár ehhez az is kell, hogy különálló /home partíciód legyen). Ha a /home egy külön partíción van (az SSD kis mérete miatt nem tartom praktikusnak ezt a megoldást), akkor sudo fstrim -v /home parancs is kell

    a mesterIgaz. Bár a cron-nál meg lehet, éppen akkor nem kapcsolod be, amikorra be van állítva. Mondjuk a napi tíz indítás nem általános, de hogy legyen egy ésszerű kompromisszum: anacron.

    trtMeglehet. :) Viszont plusz egy kérdés: /tmp és /var/tmp Egy Asus Eee PC-re raktam most (ismerős gépe, XP helyett), 4GB és 16GB SSD-van benne. A /tmp és /var/tmp kicsit feleslegesen íródik, így gondoltam, lehetne ramdisk. Csakhogy összesen 1GB ram van, és ez egy kicsit kevésnek tűnik. Tipp? Hagyjam a fenébe?

    • trt válaszolt erre.

      trtElvileg nincs külön /home partició Így néz ki az fstab: / was on /dev/sda5 during installation UUID=8ccf5410-db6d-4c50-96a1-a959a1562a2f / ext4 noatime,errors=remount-ro 0 1 rc.local pedig így: #!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. fstrim -v / exit 0 Rendben van ez így? Nem vagyok guru,így nézzétek el ha nem vagyok mindenbe biztos :-)

        magnatElvileg így jónak kell lenni, ha az rc.local mellett döntesz (és tuti megfogadod, hogy csak egyszer kapcsolod be naponta a géped. :DDD )

          Sziráki TamásMiért lenne baj az ha akár minden percben lefutna a parancs? Ez nem hat negatívan az SSD-kre, éppen ellenkezőleg. Inkább az a heti lefutás az ami kicsit túlságosan is laza. Van aki azért vette, hogy használja is, és nem azért, hogy a széltől is óvja. Jó, hogy nem mindenre jó csak arra nem amire való. Archiválásra nem jó, mert kicsi és drága. De sok írásra sem jó mert nem tesz jót neki. Talán kutyát dobálni még alkalmas lehet.

            magnatNyugodtan indítgass újra akár többször is, nem lesz neki semmi baja. Discarddal sokkal többször trimmelne, és az is csak jót tenne neki.

            magnatEgy próbát ajánlanék: másolj fel pár fájlt, majd töröld le. Utána futtasd le a trim parancsot. Ekkor is nullát ír ki?

              Lám érdemes volt feltenni a kérdést, igencsak sok új információ is megjelent itt, amivel eddig nem találkoztam. köszönöm a konstruktív hozzászólásokat, ötleteket. Azért annyi még elbizonytalanít, hogy ahányan írtak, annyi féle megoldás....de legalább mostmár van miből szemelgetni. Azért azt hiszem megoldottá tehető a kérdés. Még egyszer köszönet mindenkinek.

                drenenerdIgen,és is mindig addig jutok hogy vannak megoldások,de hogy melyek a nekem valók,az sosem derül ki :-) Mindenki mást mond jónak.....

                  trtÉrdekes most beirtam úgy hogy nem másoltam semmit sem: /: 190889984 bytes were trimmed aztán 5mp múlva: /: 97267712 bytes were trimmed Még 5mp: /: 58970112 bytes were trimmed még 5: /: 0 bytes were trimmed

                  • trt válaszolt erre.

                    magnatAzonnal visszaadja a parancsjelet? Nálam az utasítás 10-30 másodpercig dolgozik, majd utána írja ki az eredményt.

                    Sziráki TamásPassz. Esetleg 50-100 megabáj lecsípése elég lehet ramdiszknek, és talán a rendszer is megelégszik a maradékkal. Ki kell próbálni. Mindenesetre a df -h kimenetekből látszik, a meglevő ramdiszkek nincsenek kihasználva, egy-két százalékkal futnak...

                    magnatDiscard csatolási opció: + Jó, mert azonnali, és nem blokk szinten működik, hanem tudatja az SSD vezérlőjével, hogy az adott adat nem létezik többé. A vezérlő pedig tesz róla, hogy a legkisebb szinten megtörténjék a törlés. - Rossz, mert ez adott esetben sok blokkbeolvasással, adatmódosítással és blokkújraírással járhat. Ettől a sok kicsi fájl törlése valóban lassabb lehet mint trimmelés nélkül. Meg egyébként sem mindegy, hogy fizikailag történik-e törlés, vagy csak logikailag. Csak fstrim: + Jó, mert a törlési műveletek sebessége mindig optimális, hiszen extra olvasásra és írásra nincsen szükség. - Rossz, mert csak blokkszinten képes megmondani az SSD vezérlőjének, hogy nincs szükség már az adott adatra. Az írási műveletek lassabbak lehetnek emiatt, és akkor ha viszonylag ritkán van futtatva a parancs. Egy kisebb SSD a használattól hamar teli íródhat, a vezérlő pedig gondoskodik róla, hogy szétoszlassa az adatokat. Ez utóbbi művelet viszont nem optimális. Belső utasításokra olyan adatmozgatásokra kerül sor, amelyekre valójában nincsen szükség, hiszen logikailag már nem is léteznek. A fizikailag teli írt SSD-n pedig az optimalizáló műveletek több írással járnak az erre fenntartott tárterület felhasználásával. Igazából nem tudom, hogy milyen teszteket végeztek az Ubuntu fejlesztők, de elméletileg a heti egyszeri fstrim parancs futtatás egyáltalán nem optimális. Nemcsak az SSD írási sebességére vonatkozóan, de az élettartama is jelentősen csökkenhet a discard csatolási opció használatához képest. Nekem speciel párpercenként több száz MB-nyi trimmelhető adat keletkezik az fstrim szerint, anélkül, hogy egyébként bármit is csinálnék a böngészésen kívül.

                      Swap partíció helyett egy ideje zram-ot használok. Telepítéskor eleve nem adok meg swap területet, szól is érte a telepítő, hogy ha telepítés közben elfogy a RAM akkor problémák adódhatnak, 2GB RAM-om van, eddig nem volt probléma a cserehely hiánya. Telepítés, frissítés után első dolgaim közt van a bum és a zram-config telepítése, bum-ban szoktam beállítani, hogy automatikusan induljon a zram (meg letiltok ezt-azt).

                      • trt válaszolt erre.

                        KendekAz utolsó két mondatra reagálva: – élettartam: ez csak attól függ, hogy egy adott cellát hányszor ír újra az SSD vezérlő, ill. egy cella hány újraírást visel el. Ha ez az érték mondjuk, százezernél van, akkor egy pl. 60 GB-os eszköznél 60x100000, azaz kb. 6000000 GB-nyi (6000 TB) adat kiírása után várható az eszköz végleges elhasználódása, azaz tönkremenetele. Ahhoz képest a SMART szerint jelenleg itt tartok: 241 Lifetime_Writes_GiB 0x0032 000 000 000 Old_age Always - 35 242 Lifetime_Reads_GiB 0x0032 000 000 000 Old_age Always - 16 Nekem reggel óta "csak" 725 MB-nyi trimmelhető adat keletkezett.

                          trtSajnos ott tartunk, hogy nem százezer (mint a régi SLC-k), hanem csak ezer (mint a ma terjedőben lévő TLC) újraírást visel el egy cella. A SMART által kijelzett írási mennyiségen felül még elég sok belső adatmozgatás is történik az egyenletesebb elhasználódás biztosítása érdekében. Valamint pl. az igen népszerű Samu EVO-k esetében még ott van a TurboWrite is, ami a lassabb írási tempó kiküszöbölése érdekében legalább kétszeres írási mennyiséget jelent (3 GB erejéig). A lényeg, hogy ezt így nem nagyon lehet kiszámolni, de átlagos használat mellett is azért 5-10 évig bírnia kell egy SSD-nek. Az elméleti érték az évek folyamán egyre csökkent ez tény, de igazából a gyakorlatban mindegy, hogy 50 vagy 10, mert ennyi időt senki sem fogja használni az SSD-jét. Sajnos a Kingston V+100-amból nem lehet kiolvasni az írási mennyiséget, de egy év és egy hónapnyi bekapcsolva töltött idő után sincsen neki semmi baja (már jó pár éve megvan és nem kíméltem). Legalább ilyen jó teljesítményt várok az új 120-as EVO-mtól amit nemrég vettem, még akkor is ha külsőleg baromi gagyinak tűnik a V+100-hoz képest (semmi tömege sincs, a matrica is ferde és buborékos).

                            Kendek"külsőleg baromi gagyinak tűnik a V+100-hoz képest (semmi tömege sincs, a matrica is ferde és buborékos)" De ettől lett jóval olcsóbb is.