Nagyszerű! Telepítés előtt érdeklődhettél volna annak módjáról, semmi gond nincs egyébként, csak a rendszer a lehető legidiótábban partícionált. Ha legközelebb telepítesz, akkor a kézi ill. valami más opciót válaszd a partícionálásnál! Itt egy régebbi leírás róla.
Most neked csinált a rendszer egy óriási elsődleges partíciót és egy kiterjesztett partíciót, ami jelen esetben értelmetlen, mert a kiterjesztett partíció lényege, hogy mbr esetén négynél több részre is lehessen partícionálni. Például van egy elsődleges 20 GB- al és a többi kiterjesztettnek van partícionálva, így akár 10- 20 logikai partíciót is létre lehet hozni.

Ahogy látom, a rendszer mind a 128 GB- ot használatba tudja venni, emiatt csináltam volna kb. 8 GB partíciót, amit az Overprovisioning miatt nem vennék használatba, de a rendszer tudná TRIM- melni! Gondolom odafigyelsz majd, hogy ne teljen be soha az SSD, erre a mostani felállásnál nagyon figyelni kell!

Különben így is egész jó lesz a rendszered, ha nem telepítesz más oprendszert az SSD- re. Jó választás volt a Samsung és a Mint, ezek jól tudnak működni együtt.

[ Szerkesztve ]

Berus.berus javaslatára a noop-ra állítottam, de hogy őszinte legyek én képtelen vagyok megítélni, hogy jobb-e így, mint a deadline-nal. Ő nagyon mondja, hogy jobb azzal, így biztosan igaz.
Alapból minden deadline-on volt, így átállításnál igencsak figyelni kell, nehogy a HDD-t is átállítsa a zember, mert annak nagyon nem jó a noop!

Samsung 120 Gb 830 Most akkor van ilyen, a múltkor mint ha arra jutottunk volna, hogy 830-as csak 128 GB-os van, épp az overprovisioning volt a téma. Nézd már meg pontosan és kíváncsi vagyok, hogyan oldod meg az op-t?

discard, noatime, deadline beállítva, trim ellenőrizve,

-ha ennyit tettél, az már bőven elég az optimális működéshez, memóriafüggő, hogy mennyire tudod/érdemes a tmpfs-be pakolni dolgokat

Windowssal nem volt érdemben használható, most viszont öröm nyomkodni
bocs, de ezzel nem nagyon tudtál meglepni!

[ Szerkesztve ]

Azt javaslom, hogy gyakorlásképpen a HDD-n csinálj 15 GB ext4 fájlrendszerű partíciót és arra tegyél egy könnyen használható Mint-et és azon tudsz ismerkedni a rendszerrel. Se swap, se /home külön ne legyen, csak a / ahogy az iménti képen láthattad is!
Gyakorlásra tökéletes lesz, lesz mit gyakorolni!

(#41185) kkdesign
Értem, látom 128 GB-os az SSD-d, de 29 GB-ot tartalékolni értelmetlen akkor is, 7% maximálisan elég az overprovisioning-hez és ebben benne van az is, amit a Win nem használ!

Fekete képernyő az előfordul, inkább ilyesztő, mint veszélyes, nézz csak be az Ubuntu hivatalos fórumára, a tegnap megjelent 15.10 is okozza ezeket, van is para rendesen! Minimális gyakorlat kell azért ilyenkor, hogy megoldjuk a dolgot, én ezért is tettem fel Debiant nemrég, na az tanít rendesen, mikor se kép se hang nincs! Az a baj, hogy hamar elfelejtem a megoldási módokat.

[ Szerkesztve ]

29 GB szabad most a 100ból. a Többi SSDnek lefoglalt plusz hely.

Most látom csak, hogy még a 29-en kívül is van lefoglalt hely! No, ez teljesen luxus és felesleges, ha nagyon akarod, hagyj meg overprovisioningnak 10%-ot, akár partícionálatlanul is lehet, de csak akkor van jelentősége, ha az összes élő particiód dugig van!

Gyakorlatilag közel az SSD fele kihasználatlan! Olvastad valahol, hogy ezt érdemes így csinálni?

2-3 Linuxot is felrakhatsz rá és még vígan elvan úgyis!

[ Szerkesztve ]

Mivel 120-as és nem 128 GB-os az SSD-d, így főleg elég az overprovisioning, mivel itt gyárilag elérhetetlen területtel van ez megoldva a minimális 7% OP Tehát, ha semmit nem adsz meg, akkor is van 7% overptovisioning-od az SSD-n. Ha nem is pontos minden érték, de ez a lényege a dolognak.

[ Szerkesztve ]

És a maradék a 120gb-ból formázatlan, mert úgy mondták, hogy így is meg lehet oldani, hogy az SSD ne legyen soha tele.

Ha úgy mondták, biztosan úgy is van.

Mivel 120-as és nem 128 GB-os az SSD-d, így főleg elég az overprovisioning, mivel itt gyárilag elérhetetlen területtel van ez megoldva a minimális 7% OP Tehát, ha semmit nem adsz meg, akkor is van 7% overptovisioning-od az SSD-n.

Gyakorlatilag kidobtál 20 GB-ot értelmetlenül. A vezérlő az össz területet értelmezi, nem a partíciókat külön-külön, így ha totál teleírod a Wines és a Linuxos partíciókat, akkor is ott van a gyárilag lefoglalt min. 8GB, amit képtelen vagy teleírni!
Optimális esetben a Winen marad 40 GB az Ubuntun 20 GB használatlan terület, még 20 GB-ot félreteszel, nehogy teleíródjon!? Az SSD vezérlőnek ez 80+8 GB szabad hely!

Ezeket ne úgy értelmezd, hogy lefoglaltad és elveszett ez a hely a vezérlő számára:

70gb Windows 10
30gb Ubuntu

Melyik disztribúciót ajánlanád, ha munkára kell?

Ez sem egyszerű kérdés, mivel bármelyik jó gyakorlatilag, inkább az dönti el ezt, mennyire ismered, mennyire akarsz vele foglalkozni nem GUI-s szinten. De ha már Debian vonalon voltál eddig, akkor ismerősebb lenne ez a vonal, így a Debian 8.3 is jó lenne, de ha nem akarsz vele sokat bíbelődni (esetenként a Debiannal kell) akkor egy Linux Mint 17.3 Cinnamon is mindenre jó letöltés, de csak torrent linkkel!. Ezek a disztrók nem a legfrissebb csomagokkal futnak, inkább a stabil, tesztelt verziókkal. Ha mindíg friss csomagokat szeretnél, akkor az Arch vonal lesz a megfelelő az ugyanis rolling frissítésű, mindig a legfrissebb csomagokra frissíthető.

120-as SSD-m van, ebből 50 giga szabad, szóval akár rá is férne a Linux
Viszont lejárt róla a gar, nem nyüstölném 2 oprendszerrel.

50 GB-ra 3 disztró is simán elfér, alapból 6-8 Gb helyet foglal telepítve a rendszer, ha még tele is raknád programokkal, akkor is 20-30 GB a max, amit érdemes hagyni neki. Semmilyen plusz nyüstölést nem kapna, bőven maradna szabad hely az overprovisioningra is, eleve 8 GB gyárilag le van foglalva erre a célra, ami a minimum 7%. Pár ellenőrzést és optimalizálást érdemes elvégezni, itt vannak erre leírások, linkek.

Az is megoldás persze, ha veszel egy másikat és teljesen külön futnak az oprendszerek, bár egy SSD-n sincs közük egymáshoz, GRUB-bal kiválasztod és tudomást se vesznek egymásról, igaz a Linux legalább ismeri az NTFS-t.
15 eft. körül én is vettem a minap egy Adata 128 Gb SP9200-at, az ajánlott az SSD vétel topikban és van hozzá beszerelő keret plusz 7 to 9,5 mm-es magasító keret is. kép kibontás után

[ Szerkesztve ]

Szia!

Ilyen kifejezetten kis SSD-re nem láttam leírást, de nincs igazából jelentősége, az a lényeg, hogy az SSD-nek hány százaléka marad szabadon! Ez lenne az overprovisionig, ami miatt kell 7-28 százalék üres ill. nem használt hely, ez lehet akár particionálatlan is, de nem érdekli a vezérlőt ez, csak szabad hely legyen!

A gyárilag elkülönitett hellyel rendelkező SSD-nél ráadásul igazából már megvan a szükséges minimális overprovisioning-ra a hely. például az én Intel 520-asom 120 GB-os, nem 128, így már el van különítve a 8 GB gyárilag.

A trim gyakorisága is a felhasználástól függ, normál home user használatnál bőven elég a heti fstrim, ami a mostani disztróknál alapból lefut. De ha nem kifejezetten blacklist-ben szereplő SSD-ről van szó, akkor az fstab-ba beírt discard opció is tökéletes a heti fstrim mellett.

[ Szerkesztve ]

Egyébként a szakértők mondjuk javasolhattak volna 16GB swap particiót, ha már..... Ennek lenne értelme, mert tutira meglenne az overprovisioning-nak szükséges minimal hely. Ami gyárilag a 256GB-os SSD-nél nincs lefoglalva. (talán sokan nem is tudják miért van 120 és 128 GB-os SSD is)
Ha már szaktekintélykedünk, ezeket is el kéne mondani, mert előfordulhat, hogy a többi partició tele lesz és akkor......

Ha meg nagyon swap-mániásak vagyunk, akkor zram mégiscsak, mert az nagyságrendekkel gyorsabb, hiába van a swap SSD-n! Bocsi, hogy laikusként belevauzok. Aki nem hiszi, olvasgasson utána.

Ha valaki pedig Linuxot akar a gépeire, ne erőlködjünk már, hogy jajjjjj inkább hagyd meg a Wint is dual-ban, mert jujdejó lesz az kitudjamikor.

[OFF]no offense[/OFF]

[ Szerkesztve ]

A swap partíció pont hogy elveszi a területet az overprovisioning elől

Ebben mennyire vagy biztos? Csak mert ennek az OP-nek nincs sok köze a TRIM-hez szerintem. Bármilyen nem használt terület megfelel. (úgy tudom, hogy tökmindegy, particionálva van-e a hely vagy nincs, csak adat ne legyen rajta)
Lehet, hogy én tudom rosszul. Csak emiatt említettem a 16GB-ot, messze állt tőlem, hogy én bármekkora swap-ot javasoltam volna, biztosan gyorsan olvastad át, amit írtam.

OP-nek 7-28% kell, ha már százalékokkal szaktekintélykedünk.

""
Az overprovisioninggal nem kell amúgy sem foglalkozni, azt lehet tenni az érdekében, hogy nem szabad szarásig pakolva használni az SSD-t, hanem arra figyelni,
""

Értem. Nem kell vele foglalkozni, de arra kell figyelni, hogy...... Látsz ebben Te is némi ellentmondást?

[ Szerkesztve ]

A leírást köszi szépen mégegyszer, jó volt rajta elindulni

Igazán nincs mit, kicsit meglepett, hogy abból valaki még profitálhat! Szerencse, hogy a múltkor nem töröltem .

A dev/shm az alapból a RAM-ba mutat

Valami már rémlik, hogy nemrég témáztatok ezen itt valakivel, még soha nem foglalkoztam ezzel az shm-mel, de ahogy látom valami használja most is....

Fájlrendszer Méret Fogl. Szab. Fo.% Csatol. pont
udev 7,5G 0 7,5G 0% /dev
tmpfs 1,5G 1,9M 1,5G 1% /run
/dev/sda5 25G 11G 13G 47% /
tmpfs 7,5G 296M 7,2G 4% /dev/shm
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 7,5G 0 7,5G 0% /sys/fs/cgroup
tmpfs 800M 191M 610M 24% /home/ubyegon/.cache
/dev/sdb6 233G 133G 89G 61% /media/ubyegon/TT
/dev/sdb7 20G 3,7G 15G 20% /media/ubyegon/PCX
/dev/sdb5 601G 311G 260G 55% /media/ubyegon/TORRENTEK
tmpfs 1,5G 56K 1,5G 1% /run/user/1000
/dev/loop0 1,5G 1,5G 0 100% /media/ubyegon/NITRUX
/dev/loop1 274M 274M 0 100% /media/ubyegon/CDROM
/dev/sde1 15G 1,6G 13G 12% /media/ubyegon/PENDRIVE

Firefoxot sem oda szoktam rakni, de lehet kipróbálom, most csak úgy van, ahogy települt.
Zram-ról olvastam anno, szerintem is nagyszerű megoldás! Ha kevés memóriám lenne, használnám is, egyszer kipróbáltam, talán a RAM felét csinálta meg automatikusan zram-nak.

Ugyan maradt kb 6-7GB partícionálatlanul,szabadon, de azt sok helyen azt írták, ajánlott is az SSD-knek(~10% szabad hely).

So so....7-28% van overprovisioningra írva. Nálad a minimum szinte meg is van gyárilag, mivel a 64GB-ból 4-et nem is tudsz alkalmazásba venni. Egyébként ilyen kevés hely esetén és a gyárilag lefoglalt hely miatt én nem is hagynék meg particionálatlan helyet. Ott a cc. 7%, no meg a particionált területek szabad helyeit is üres területnek használja a vezérlő.

Használja az fstrim.timert a disztró, azt kikapcsoljam?

Felesleges kikapcsolni, mindenütt azt írják, elférnek egymás mellett, az a heti lefutás nem okoz plusz gondot, de ha kilövöd, az se gond, az online trim úgyis ott van.

Elég a systemctl stop+disable fstrim.timer, vagy kell a mask is?

Csak stop és disable, a mask az teljesen más, most nem emlékszem már pontosan, de ebben az esetben az nem célszerű.

A deadline schedulert használom az SSD-hez, ezt vagy a semmit ajánlotta a tutorial Gondolom a "noop" az a semmi.

A deadline szerintem a legtöbb helyen az alap, de csak azért, mert a noop a forgó eszközökhöz nagyon nem javallott! Mindenhez jó a deadline, mondjuk SSD-nek a noop az, amivel lubickol, csak ha beállítod, figyelned kell, hogy a HDD-re nehogy az legyen érvényes.

[ Szerkesztve ]

Milyen SSD-re gondolsz? Tudod mi a különbség a 120 és 128GB-os SSD-k között? overprovisioning a kulcsszó!

röviden

Én ezt úgy oldottam meg, hogy eleve ennyivel kisebb partíciót hoztam létre, így nem felejtődik el

Pazarlás! Millen SSD-d van amúgy?

[ Szerkesztve ]

OK, tegyük fel, hogy a 480GB-ot ext4-re megparticionálod. Egyben vagy többfelé, ez mindegy. Itt a gyártó nem foglalt le helyet, de már van 12GB-od, amit lefoglalt a fájlrendszer. Ha kb 95%-osan telerakod az SSD-t adattal, akkor kb eléred a 7% minimumot, ami az optimalizált overprovisioning alja.

Nyugtass meg, hogy ha a particiókon 95% telítettséget eléred, azt már azért csak észreveszed!
No meg az UV400-at nagyon nincs értelme óvni semmitől!

A default ext4 mount opciókra azokat az értékeket írja példaként, de akár.....na mindegy, nekem az a furcsa, hogy eddig más disztrók ezt nem használták, az async opció viszont egyes schedulerek esetén nem biztos, hogy szerencsés, most meg nem mondom, hogy a bfq vagy a noop vagy akármelyik az IO szinkronnal is ügyködik.

[ Szerkesztve ]

Bőven elég 30 is, de adj 50-et, bár 5-6 évig úgysem fogod használni, hiába van ez a rolling mese.

12GB ram mellé ha 5GB swap-ot állítok be az elég lesz?

Nem néztem meg minap, Manjaro csinál-e swap fájlt, de 12GB mellé Ubuntu-k 1GB-ot csinálnak a biztonság kedvéért. Sosem fog több kelleni, ha viszont ez is kevés a fizikai mellett, akkor valami anomália van, ott meg ki tudja mennyi lenne elég. Amúgy hasznos is lehet, ha 5GB-ot csinálsz, mert az is hozzáadódik az overprovisioning miatt fontos gyárilag félretett helyhez, így tuti meg lesz a minimum elvárt 7%. (ext4-ek is tesznek félre, etc.)

Szóval akkor legyen 50 és 5GB.

(#71259) májkimiki

Én meg főleg ősbölény vagyok. Pár éve kezdett feltünni, hogy egyre több csomag az /opt-ba fészkeli magát, de most már szinte csak oda.

(#71257) Doky586

Az fstrim a szabad helyeket is trim-meli, úgy tudom, de értelemszeráen nem bántja az NTFS-en lévő adatokat, hiszen ugyanaz a vezérlő dolgozik Linux alatt is, mint Win alatt, de ezt Te jobban tudod nálam.

sudo fstrim -a parancs TRIM-mel minden csatolt meghajtót, erre érdemes odafigyelni, mert jártam úgy, hogy live Linux alatt TRIM-meltem volna, de elfelejtettem felcsatolni a meghajtókat. Fura volt, hogy túl hamar végzett.

[ Szerkesztve ]

Ja hogy emiatt kérdezted, értem már. Sose csináltam még ilyen furfangos dolgokat. Nem is biztos, hogy jó így máshonnan linkelni, mert lassú lesz. minimum

mikor ssd -n kifutottam a helyből

Emiatt meg nem csak a linkelt program lesz lassú, lásd imént érintett overprovisioning téma. 7-28% használaton kívüli hely. consumer - professional a két érték végpontja.

Sose közelítsd meg azt az állapotot, hogy kifutsz a helyből SSD-n!

[ Szerkesztve ]

Aham, már emlékszem, ill jól emlékeztem a Samura, de erről már amúgy ejtettünk is talán pár szót, legfeljebb nem Manjaroval.

nem éri el, csak, ha manuálisan odavezénylem a letöltési ablakban.

Ez így nekem értelmetlen, ha nincs manuálisan sem csatolva, akkor nincs csatolva, amiről itt írsz az az elérési út megfelelő beállítása mind böngészőben, mind letöltésvezérlő kliensben. Hiába fogod felcsatolni manuálisan vagy az FSTAB-ba beírva, ugyanúgy a default elérési utak lesznek az említett helyeken. Ráadásul ez még csak nem is Linux sajátosság, más oprendszernél is ez van.

Mivel gyárilag csak 6GB/12GB(256/512) van elkülönítve, minimálisan 5%-ot el kell különítened az overprovisioning miatt, ezt gondolom tudod.

[ Szerkesztve ]

TRIM ellenőrzése, Ubuntu alapnál az fstrim időzített trim-et csekkold, a Reborn OS-nél elképzelhető, hogy online TRIM van beállítva, nézd meg a cat /etc/fstab parancs kimenetét.

Archklónoknál, discard,noatime paraméterek vannak.

Hogyan tudom ellenőrizni, hogy az SSD-n van-e olyan tartalék hely, hogy nehogy elfogyjon és a rendszer megpurcanjon

Szerintem a szemeddel. Látható, hogy 120GB-os meghajtóról van szó, így tudjuk, hogy a gyárilag lefoglalt overprovisioning az 8GB, ehhez hozzáadódik az EXT4 fájlrendszer által lefoglalt 2,5% és ott vannak még a particiókon a fel nem használt helyek. Ezeket az SSD vezérlője mind-mind használni fogja. Nem számít, hogy particionált hely vagy partició nélküli.

[ Szerkesztve ]

journalctl | grep fstrim

Ha csinálsz egy gyors manual TRIM-et, annak is rakd be a kimenetét léci:

sudo fstrim -av

Még inkább érdekesek a fenti parancsok, mivel az első parancs kimenete alapján támogatott a TRIM, de ez ilyenkor ugye nem annyira egyértelmű mégsem.

Látom már!

Célszerű lenne vagy a discard opciót beraknod FSTAB-ba vagy az fstrim-et ütemezni mondjuk heti rendszerességre. De ha elég szabad helyed van, akkor az is bőven elegendő ha pár hetente lefuttatod a manual TRIM parancsot, pár napja olvastam, hogy a relatív nagy overprovisioning mellett akár szükségtelenné válhat a TRIM. Gondolom emiatt van az, hogy a gyártó 7-28% overprovisioning-et javasol, a consumer SSD-nél 7%-ot alkalmaznak gyárilag, a professional meghajtóknál viszont 28%-ot. (már amelyik alkalmazza mindkettőt)

[ Szerkesztve ]

No így már értem, miért kellett nagyon tervezetten költened a forintokat! Ha ennyi dolgot vásárol egyszerre az ember, akkor már tényleg körül kell járni a témát.

Ha így oldottad meg két darabból a meghajtók kérdését, így is tökéletes lett, én amiatt is említettem az 500GB-os WD Blue 3D-t, mert azzal egyben megoldottál volna mindent. Külön tárolásra teljesen jó a WD Green is.

Az, hogy egy SSD mennyire ajánlott vagy sem érdekes, a Samu 840-em sem volt ajánlott, sőt...

No itt azért időzzünk el kicsit, az, hogy valami ajánlott, nem csak arra vonatkozik, hogy mennyire tartós. Rendszer és általános napi feladatokra mindenképpen Blue javasolt a Green helyett és figyeld csak a következőket! Bár lehet, hogy ismered ennyire a témát, akkor majd okul belőle más, aki olvassa. Kb annyi a különbség, hogy a Green a 256GB-ból 240-et enged a felhasználónak birtokba venni, a Blue meg 256-ból 250-et. Előbbiben nincs DRAM memória a cache-nek, valószínűleg ezért 10GB-tal többet hagytak gyárilag lefoglalt helynek, hogy az overprovisioning optimálisan biztosítva legyen és ne tudjon belassulni az eszköz végletesen. Blue esetén van DRAM cache, emiatt válik alkalmasabbá rendszerfuttatásra és általános napi használatra. Fura, de tárolási célokra épp egy 250GB-os lenne megfelelő DRAM cache nélkül, de mivel a felhasználók azt is használnák minden másra is, így a gyártó gondolkodik helyettük.

A Samu 840-nél voltak problémák, amiket ha jól emlékszem fw frissítéssel orvosoltak, ott sem a tartósságával voltak gondok.

Szerintem nyugodtan használd az SSD-t, az amit leírtál, az lófütty felhasználás, ha még az SSD-ről is lehetne tudni valamit...... , de amúgy ha viszonylag új tipus, akkor neked bőven elég oda a garbage collection is. Linux oldalról csak az FSTAB-ban alkalmazható discard opció működhet vagy a cron, de mondom, felesleges ez is. Beírod FSTAB-ba a discrad-ot és kész, majd egyszer kidobod az elhasznált SSD-t. A két időpont között feledkezz is meg róla nyugodtan. Max az overprovisioning-gal érdemes foglalkozni, ha gyárilag nincs lefoglalva min 7%.

Ja igen, nincs init rendszer abban a valamiben, ne is keress, azért vannak csak a fenti lehetőségeid.

[ Szerkesztve ]

Akkor legyen jó az a RAM, mert az említett SSD-ben SDR cache van, pont úgy, mint ebben a tök ugyanolyan SSD-ben
Viszont ha lesz 4GB RAM, akkor teljesen jó lesz az a gép, amit páran mondtak, hogy ki kell dobni, az azért elég meredek nekem. Még mindig ott lesz az említett RAM tömörítő eljárás, amit nemrég kolléga be is írt ide, a zram.

Viszont amit gyakorlatban nem nagyon próbáltam jó ideje, azok a YT player appok, amik jóval kisebb erőforrást használva játszanak le link alapján, mint browserből használva a YT-ot! Aki még használ ilyet, leírja, melyik ami most működik!

A jó SSD-k 250GB-osak, általában a méretből tudni, mire számíthat az ember. A 240-es értelemszerűen több GB-ot rejt el a user elől, hogy a vezérlő tudjon jobban trükközni, mivel nincs cache. Gyaníthatóan overprovisioning célokra van ez a 16GB főleg félretéve.

Ha látnál aprón 860 vagy 870 EVO 250GB-os SSD-t azzal járnál a legjobban egyébként, de még a WD Blue 3D 250GB is jó lenne! Előbbiekben 500MB, Blue-ban 250MB a DRAM cache. Bár tény, hogy ez inkább szekvenciális írásnál lényeges.....

[ Szerkesztve ]

Ez is hasonló volt, fusd át Bob koma hsz-ében van a jó tipp, egyébként ha nincs LVM, akkor magát a crypt service-t kell eltávolítanod, szerintem ha a csomagot törlöd, a hiányoló services szórakozni fog továbbra is.

SSD-re meg smartctl, hátha lefut USB csatolással is....egyébként a boot-on kívül mi más miatt gondolod, hogy baj van az SSD-vel?

vagy kevés rajta a tartalék hely

Ez lassíthatja jelentősen, kérdés, hogy valóban kevés-e a hely az overprovisioning-nek? Ezeket a dolgokat nem lehet tippeléssel kiókumulálni sajna. (hacsak nem vagy jó látóasszony.....)

A pantheonnak annyi hiányossága van, hogy nem lehet a tálcára lelökni a futó programokat, amikor épp nincs rájuk átmenetileg szükség.

Ez kb elég is ahhoz, hogy használhatatlan legyen, ha megszoktad a több ablakkal operatívkodást. Kipróbáltam, rettenetes élmény volt, több ablak meg volt nyitva és fogalmam se volt, hová kattintok és miért nem mozdul semmi, bár lehet a sötét háttér is akadályozott kicsit.... Persze ha felraksz ezt meg amazt, mint Ubuntunál a tweak, meg dconf-ot használsz, akkor OK lesz, de pont egy ilyen disztrónál ez nem tűnik előnynek. Aki tud és akar ennyit gépészkedni, az éppen nem ilyen disztrót fog felrakni.

[ Szerkesztve ]

splasscreen

Azóta keresi a crypsetup partíciót bootoláskor, de az ökörkéje aztán megnyugszik és mégis bebootol (hát akkor minek az neki ???)

Mindent keres egy beállított ideig, ami a rendszerbe be van konfigolva, services például, ja és azért mutatja egyébként, hogy a bootkor lefutó splasscreen-ben lásd ezeket, de ugye alapból ez quiet állásban van, ha malmozik a boot, érdemes az Esc lenyomásával megnézni, mit ír ki a splasscreen.

A trimet kivizsgáltam , nincs vele semmi baj, jó ez a pici külsőházas Sony SSD.

És mi van az üres tárhellyel? Tudod mennyi gyárilag lefoglalt overprovisioning van az eszközön? Mi ez pontosan, csak kíváncsiságból? Ritkán hallani Sony SSD-ről.

Szerintem ez a systemd-cryptsetup nem csípi, ha már a partició titkosítás után babrálnak vele, lehet hamarabb testreszabnál egy pure install Arch-ot, mint ezt a csuda eOS-t.

[ Szerkesztve ]

Az a pendrive már repüljpáva kategória valóban! A képen látható olvasás nem rossz amúgy, kb egy PCIe 4.0 NVMe SSD sebességét hozza, ami ugye fura, mert a legnagyobb elméleti USB 3.2 sebesség az 1250 mbps...

A kimenetben ezek a controller not responding, I/O error és társai jelzések us azt mondják, hogy normál működő rendszerbe ne dugdosd a pen-t, mert a beolvasási és egyéb műveleti kísérletek lelassíthatják a rendszert és akkor nekiugrasz, mint röfi az ólajtónak és elállítgatsz valid konfigokat is ügyesen.

A swap kérdés....hát ugye először megnézzük, hogy default mennyi swapot csinált a rendszer és utána kezdünk variálni. Alap userkedésre bőven elég az a swapfile, ami a rendszerrel jön. help

Igaz persze, hogy a Linux Mint Cinnamon igen stabil rendszer, de persze megsínyli az is, ha megpróbáljuk megöldösni mindenféle kevéssé átgondolt bíbelődéssel!

Minap itt is láttam egy kérdésed, de oda már nem nagyon irkálok....szóval semmi fontos nem derül ki a kérdésből, ennek ellenére a szakik rá se kérdeznek és beraknak egy évtizedes WIndows 7-es linket. No mindegy, szerintem ezt az overprovisioning kérdést elég furán kezelik a szaktopikjában is! De minimum meg kellett volna kérdezniük az SSD pontos tipusát, mert abból kiindulva lehet adekvát választ adni a kérdésedre! Ilyenkor képedek el erősen, ha arra gondolok, hogy az ottani szakik eltanácsoltak, hogy én oda ne is írjak, mert nem vagyok hozzáértő.

Szóval pihenésképpen olvasgasd ezeket a hsz-eket az OP-ről, hogy képbe kerülj, mit is kéne kérdezned az SSD-d szabad helyéről. De ahogy nézem, ebben a topikban is toltam rendesen az okosságokat az OP-ről...nyilván a régebbi bejegyzések...hát azok még elég kezdő korszakomban keletkeztek, de az újakból azért tudsz kinyerni hasznos infókat.

Esetleg ezt még megpróbálhatod a pennel, de sok esélyt ne adj neki:

How I fixed xHCI host controller not responding, assume dead

[ Szerkesztve ]

az SSD-ről próbálok a HDD-re másolni, akkor kb. 2 másodperc után lemegy a sebesség 0-5 MB/s-re. Ilyen korábban nem volt és nem jövök rá mi okozhatja. HDD-ről SSD-re, samba-n keresztül SSD-re és a HDD-re is normál sebességgel tudok másolni.

A TRIM hiánya itt nem lehet ok, mivel nem az írás lassul be, hanem az olvasás, így sem a TRIM hiánya, sem az overprovisioning nem megfelelő mérete nem okozhatja a jelenséget, bár jelentős lassulást egyébként inkább utóbbi okozhatna...

Célszerű lenne az alábbi parancsot lefuttatnod, hátha kiderül belőle valami. sdx-nél az x értelemszerűen behelyettesítendő a megfelelő partició betűjellel.

sudo smartctl -x /dev/sdx

A kimenetet be is rakhatod ide (a Programkód gomb használatával nyilván), hátha valaki meglát valamit. Így elsőre vagy dugig van mégiscsak a lemez(overprovisioning) vagy egyszerűen kezdi megadni magát...

[ Szerkesztve ]

Az online(azonnali) discard TRIM és az ütemezett fstrim teljesen jól elvan egymás mellett. A discard paramétert akkor nem célszerű használni, ha nagy fájlokkal zajló I/O műveletek történnek, mert abba belekvarhat és lassulást okoz időlegesen. Emiatt tiltják az NVME SSD-nél is, mert alapból ez a nagy fájlokkal és gyors másolással operál.

A noatime opció azért jó, mert minden fájlművelethez így nem fűz naplóbejegyzést, ami által gyorsul az I/O művelet.

De ha elég szabad helyed van, akkor az is bőven elegendő ha pár hetente lefuttatod a manual TRIM parancsot, pár napja olvastam, hogy a relatív nagy overprovisioning mellett akár szükségtelenné válhat a TRIM. Gondolom emiatt van az, hogy a gyártó 7-28% overprovisioning-et javasol, a consumer SSD-nél 7%-ot alkalmaznak gyárilag, a professional meghajtóknál viszont 28%-ot. (már amelyik alkalmazza mindkettőt)

Ezeket találtam régebbi hsz-ekben, de egyébként ha nem akarsz online TRIM-et(discard), akkor beállíthatod napi ütemezett lefutásra is az fstrim-et, itt egy mód erre:

Set the automatic TRIM job to daily