- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- gban: Ingyen kellene, de tegnapra
- sziku69: Szólánc.
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- N€T0X|N: Stellar Blade után
- pr1mzejEE: Viszlát CoD2, CoD4, CS:GO!
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- weiss: Pant* rant
- Bezzeg annak idején...
-
LOGOUT
Linux kezdőknek - érdemes beleolvasni, mielőtt kérdezel
Új hozzászólás Aktív témák
-
Dißnäëß
nagyúr
Semennyire, a raid tömböd nagyonhamar gyorsabban tud olvasni, mint a cache-nek (tisztázzuk: READ cache-nek, azaz L2ARC-nak) használt HDD.
Felejtsd el, a legbikább NVME-t kell L2ARC-nak betenni, lehet kicsi is, vagy amire a pénzed futja, de gyors legyen, nálam 4 HDD olvas 700MB körül (persze 1 nagy fájlt, nem sok aprót millió seek-el), szóval egy SATA SSD is sovány lenne (kettő már okébb)... na az megküldi rendesen a pool sebességet. Mondjuk a nagyobbak többet is bírnak (TBW) és jót is tesz úgy mindennek általában.
VM-ek (és DB-k és 1-2 dolog) a default async helyett sync módon írnak a poolra, azaz akkor tekint a rendszer valamit kiírtnak, ha az ténylegesen kiírásra kerül... így arra LOG (SLOG) device-ot érdemes csinálni, szintén SSD. Ez write cache, míg az L2ARC read cache csak.
Az egész pool alá pedig lehet SATA SSD-kből, minimum 2-utas mirrorból, de inkább 3-ból (mert ha bekrepál, befosik a teljes pool) special device-t csinálni, ami a metaadatokat tárolja itt (nem pedig a HDD-n) illetve default tán a 128K-nál kisebb fájlokat, de ez állítható, pl. minden ami 8 megánál kisebb, erre jöjjön, minden, ami nagyobb, a HDD-re. Special device-t utólag is lehet hozzáadni meglévő pool-hoz, viszont csak új írások metaadatai kerülnek az SSD mirrorra, a meglévők már nem, ezért érdemes pool létrehozáskor meglépni ezt, akkor az optimalizált.
Fullextrás esetben lenne egy pool és hozzá special device (2-3 utas mirror SSD), log device (1 vagy több SSD) és cache (1 vagy több SSD) egyaránt.
Ezekből a LOG-ot érdemes tükrözni, de ha nem tükör, nincs tragédia, akkor sem, ha meghal (max pár utolsó tranzakció vész el), régen ez baj volt, de már rég kiszögelték a ZFS-ből. Ettől függetlenül olcsó az SSD, két SATA-sat simán be lehet fogni erre a célra tükörben, a LOG-ra durva írás nem megy, inkább több kicsi.
A cache (L2ARC) SSD-t bármilyenre lehet venni, kommersz szar is lehet, nem fontos enterprise és akár stripe-ba is teheted egy társával, dupla sebesség (raid 0 ekvivalens). Ha hullik, belassulsz, de kb. ennyi történik, semmi különös. Én valami nagysebességű vihargyors NVMe-t fognék be erre és elég 1 db.
LOG eszköznek 1 vagy 2-utas tükörnél érdemes PLP-s Enterprise szintű SSD-t venni, hogy ha elmegy az áram, be tudja még fejezni a legutolsó megkapott adat kiírását az SSD. Nem durván kötelező, de ajánlott.
Special device már metadata szint + kicsi fájlok, ez érzékenyebb terület. Én ide szintén csak enterprise, jó írástűrésű SSD-ket fognék be, de PLP-s legyen, itt nagyon fontos, hogy be tudja fejezni a legutolsó megkapott adatot minden SSD benne, ha elmegy az áram hirtelen. Elméletben a ZFS ugye CoW, ha lemegy az áram, nincs korrupció a fájlrendszeren, mégis ajánlják. Enterprise SSD-k ilyenek.
Szóval SATA SSD-kkel meg lehet oldani mindent, ami nem cache (L2ARC), mert nincs durva szekvenciális írás-olvasás róluk. A cache eszközt érdemes a sebesség miatt NVMe-re venni.
Amit én még javaslok, az az ashift=12, a szektor méretet amit a ZFS alapegységnek használ, érdemes a default 9-ről megemelni (kettő a kilencediken, azaz 512 bájtról kettő a tizenkettedikre, azaz 4K-ra), bár sok 4K natív diszken felismeri a ZFS és ezt használja.
Egyre több SSD jön (még azért nem mind) 8k szektormérettel, és mivel egy pool-on belül az ashift érték minden eszközre ugyanúgy érvényes, a gyors mindenféle írási és olvasási cache és metaadat SSD-k optimális kihasználtsága miatt érdemes akár 8K-ra venni a szektorméretet (ashift=13), ez a 4K-s vagy 512b-s HDD-knek sem gond amúgy, hiszen a kisebb számok többszöröse.
atime off-ra, compression ízlés szerint, dedup off (ez a default amúgy) és akkor nem falja a RAM-ot (a rendszer RAM felét elveszi, de amint kéri egy app, visszaadja), ha esetleg használnál valami gluster vagy egyéb elosztott fájlrendszert felette, akkor érdemes az xattr=sa-t is beadni neki, nem nagy plussz metaadatban.
- cache (L2arc) bármekkora lehet
- special már nem feltétlen, nézd meg a statjaidat (zdb -Lbb <pool>) és látni fogod, melyik soron mi az érték a metaadatokra JELENLEG, special nélkül.. de olyan pool teljes méretének 1%-a egészséges lehet (persze nagyon pool függő, ezért érdemes statot nézni). Ha a special betelik, a HDD oldalon folytatódik a (vélhetően) most is megszokott módon a metaadatok és kis fájlok tárolása, szóval nempara, max lassulsz
- ZIL/SLOG szintén ízlés szerint, azért ne 32 Gigásat..
Szóval összességében egy komoly sebességű pool abszolút valid, de érdemes egy marék SSD-vel nekiállni. A legkönnyebb a cache eszköz, ha van egy SSD-d elfekvőben, bármikor hozzáadhatod az egészet, vagy csak egy partíciót róla (felül lesz írva), pl. mondjuk ha overprovisioning-elsz, hogy ne használja a teljes tárterületet, így valamivel lassabban kopik.
Érdemes még a recordsize=1M-et is beadni neki, 16M-ig lehetne menni, de itt már nincs szignifikáns sebességkülönbség és sok helyen azt olvasni, hogy a default 128K és 1M között az optimum. Ez maximum érték, tehát ami ennél kisebb, az kisebb record-ba lesz kiírva, ami ennyi vagy ennél több, az pedig úgy. Hatása van a szekvenciális olvasásra, a tömörítés hatékonyságára, a párhuzamosíthatóságra és még jópár dologra, szóval egy 1 megás recordsize beállítással elég faja lehet egy vegyes mindent tartalmazó pool.
(Ha csak és kizárólag nagy fájlok mennek rá, ami mondjuk nagyobb, mint hasraütök, 1 giga, lehet 16M is a recordsize érték, de marginális a haszna, 1M ideális max közeli, azt mondják).
A nap végén rá fogsz jönni, hogy miután tanultál egy rahedli dolgot a ZFS-ről, úgy szar a pool-od, ahogy van.
Ezen mindenki átmegy, aki ZFS-ezik
(Szintén zenész).Iyenkor jön az, hogy ki mindent valahova máshova, majd HDD-k legyak, faszapool létrehoz, spéci device-okat alá betol, na és majd csak ekkor mehet minden rá vissza, kölcsön HDD-t megköszön.
-
Dißnäëß
nagyúr
válasz
sh4d0w
#104377
üzenetére
Már hogy venné észre akármilyen random Linux ?
Ugyanazt a mozit nézzük ?
Egyik HDD-m a négyből, ez a nyers drive nézete (nem a /dev/mapper-es felnyitott ekvivalenséé értelemszerűen). Ez full disk encryption LUKS-al. Amit LUKS-ban lehet amúgy offset-elni, hogy ne a legelső szektornál indítsa, ergo akkor csak kevesebbet titkosít le belőle. Se kontroller, se más OS, se emberfia meg nem mondja, mi az a random szemét ...
A Windows ugyanezt látja és amikor a SAS kontrollert bekapcsolom (mert le van tiltva eszközkezelőben), detektálja mind a 4 HDD-t és megkérdezi, hogy inicializálja-e őket, mert tök szüzek. Nyilván cancel, különben száll minden, hiszen nem szüzek..Spéci szoftver is akkor tudja nagyjából megtippelni, hogy bármivel is titkosított a drive (úgy egyáltalán), ha a header-je rajta van az elején. Nálam ez sincs, külön vettem, akárcsak a kulcsokat, de ez mindegy is.. a header-t is tartalmazó nyers LUKS titkosított drive is tök láthatatlan azon OS-ek számára (mind számára), amik rajta kívül állnak. Lehet egy NSA-nek van féltve őrzött tool-ja ilyenek kinyitására, minthogy minden opensource kripto- és szteganográfiai projektben ott vannak (lásd backdoor), de most ezzel komolyan nem foglalkoznék mélyebben, meg ha vki rájönne, hogy van ilyen, az nagyot durranna.
Az, hogy Te hozol létre egy normál GPT partíciós táblát és azon belül egy formázatlan akármilyen partíciót, majd azt titkosítod LUKS-al, vagy mással, engedi magát detektálni - értelemszerűen, de itt szó nincs erről és nem is utaltam rá. A Windows partícióim között ott éktelenkedik a szintén LUKS-os linux gyökerem, evidens, hogy egy nemtitkosított táblában látszik, még label is adható neki, nem csak a típusa, hogy az ott adat lesz, ha tudod a jelszót..
Ember legyen, aki a telibe titkosított HDD-ről felnyalt "random adatszemétről" megmondja, hogy valódi fájlrendszer van felette értelmes adattal, pláne úgy, hogy nem írtam végig dd-vel nullákkal a /dev/mapper eszközt a mindennapi ajánlások ellenére, magyarul az alatta lévő rétegen sem írta random szarral tele a diszket a LUKS, csak ahova tényleg kitett adatot a felette lévő felnyitott rétegben (amiben olyan fájlrendszer van nyilván, amit csak akarunk, teljes értékű eszköznek látszik). Ergo, kívülről nézve egy editorból nagyjából random szemét és előző tulajtól származó további szemét és nullák váltják egymást.
Ha ugyanezt megcsinálod egy SSD-vel, addig fogja tudni a kontroller, hogy mely részein van értelmes adat, amíg a titkosítást létrehozó oprendszer erről árulkodik neki bármit is (mivel a LUKS is tud discard-ot, a biztonság rovására, de azért az sem úgy megy, mint a filmekben).
Ahogy bootolsz másik OS-el, a másik OS azt fogja jelenteni a kontrollernek, hogy "üres diszk" és amint létrehozol rajta egy partíciót (kicsit vagy telibe, mindegy), egy fájlrendszerrel, azonnal indul a trim parancsok kiadása és az SSD megtudja, hol van adat és mi a free space, utóbbit már szabadítja is fel.
Hja, csak közben belerondíthat az ott lévő "random szemétbe" ami nagyonis rendezett, semmi random, csak annak látszik. Ez HDD-n nem fordulhat elő, mivel csak akkor nyúl a fej ezen részekre, ha konkrét access érkezik ide, nem pedig üresjáratban is dolgozgat a háttérben és írogat felül cellákat, blokkokat, page-eket, akármiket, mert úgy hiszi hogy dolgozhat vele.
Amikor a Samsung SSD Magician is Overprovisioning-et állít be, lényegében egy formattálatlan nyers partíciót hoz létre a meglévők közé, jelezve ezzel OS-nek (és az meg az alatta lévő SSD vezérlőnek TRIM által), hogy az ott üres terület, lehet vele játszani. Holott fizikailag ki tudja milyen randomszemét van azokban a cellákban is, de az SSD onnantól simán felülírogatja őket, pakolgat ide-oda-amoda, wear leveling dolgozik, Neked meg ugrik a titkosított részed.
Mire ezeket bepötyögtem, megerősítettek, hogy csak úgy működik a dolog, ha nincs átfedés a látható - mondjuk - NTFS partíció és a mellé tett (láthatatlan) LUKS konténer között.
A működési elv: ha a fájlrendszer töröl egy inode-ot (vagy típustól függően hasonló logikai alapegységet), akkor a TRIM parancsot küldi az SSD-nek és informálja arról, hogy az ahhoz az inode-hoz társított adatblokkot felszabadíthatja. Mivel egy NTFS fájlrendszer nem menedzseli azokat a blokkjait egy SSD-nek, amik titkosítottak, nem is fogja azt mondani az SSD-nek, hogy szabadítsa fel azokat, kivéve ha kiterjesztem átméretezéssel az NTFS partíciót arra a területre is.
Magyarul, amíg a látható NTFS (vagy egyéb) és a láthatatlan titkosított adat egymás mellett vannak logikailag, nem lesz gond. Ha a látható átlapolódik részben vagy egészben a láthatatlanra, SSD esetén TRIM miatt kinyírja azonnal a láthatatlan titkosított részt ezzel, mert annak vezérlője a területtel elkezd "játszani", felszabadíthatónak tekinti onnantól, míg HDD esetén eljátszható simán, hogy egy NTFS partíciót kiterjesztünk rá a titkosított területre és amíg nem írunk rá, illetve arra a területre (amire nincs ráhatásunk), addig az nem is lesz bántva. Értelme nem sok, max fóbia-paranoia esetén, hisz veszélyeztetjük NTFS írás esetén a titkosított, ott és akkor üresnek látott területet, de mint megoldás működik.
Jót beszélgettünk.
-
#104327
ubyegon2
félisten
fekete.puma
#104325
válasz
fekete.puma
#104325
üzenetére
Ez az AI válasz használhatóbbnak tűnik!
Nyilván akkor érvényesek ezek a megállapítások, ha relatíve kevés hely van a meghajtón ill emellett kevés az overprovisioning is! Egyébként home usernek bőven elég a beállított ütemezett TRIM is a default heti ütemezéssel, de ezt is át lehet állítani napi lefutásra, ha szükséges.Az a kérdés is felmerült anno, hogy lehet-e discard beállítva és emellett aktív ütemezett TRIM is. Persze, max ha valaki hétfőn nulla órakor épp TRIM-melteti discard-dal az SSD-t, addig nem indul el az ütemezett fstrim.
-
válasz
growler
#102924
üzenetére
Ha az AI Chat azt mondja, tuti igaz lehet!
Lehet, hogy a manuális fstrim parancs meghívja a deallocate-ot NVMe esetén, de amit linkeltél példának, ott teljesen felesleges. Tényleg bőven elég a saját vezérlő által kiadott deallocate parancs és az idle-ben eldolgozgató garbage collector.Most csak Sata SSD-s notebookom van, ebben heti fstrim fut le és a két hétfői nap között, ha lefuttatom a manual TRIM-et, akár ezt is mutathatja(ez egy jelenleg nem használt felcsatolt disztró particiója):
23,6 GiB (25380712448 bytes) trimmedAz mai SSD-knél szerintem felesleges külön foglalkozni a manual TRIM-mel, ami meg két végrehajtási időszak között összegyűlik, nem okozhat semmi gondot, főleg ha van overprovisioning-nek elég helye. Plusz ha nincs kikapcsolva a rendszer és elég időt tölt idle-ben, a garbage collector tényleg elég hatékonyan elszaladgál a meghajtón. Nálam ez a fenti 23,6 GiB azért gyűlhetett össze, mert nem nagyon volt idele állapotban az a partició.
De nyilván mindenki másként látja ezeket a dolgokat, mind az overprovisioning-et, mind a TRIM-et.
Én totál átlag home user profilom mellett egyikkel se foglalkozom már ezer éve. -
válasz
.-..-.
#101922
üzenetére
A particiós képedről nem jön le nekem a 15%. De nem is ez a lényeg, azért nem kifejezetten a % említendő, hanem az overprovisioning, mert ez egy olyan érték, ami nem tőled függ teljesen, igaz csak 49GB jön rá pluszban tőled függetlenül, de az is számít. (24GB gyári overprovisioning és 25GB EXT4 foglalás a rendszernek)
Az 1GB /boot meg tud kevés lenni, ha nincs beállítva, hogy hány kernelt tartson meg a rendszer kernelupgrade-ek után.
-
.-..-.
tag
válasz
ubyegon2
#101919
üzenetére
"Épp akkor nincs szerintem, ha nincsenek külön particiók. A külön /boot lehet csapda ezek miatt: EFI, kernelek, initramfs, etc"
Ez így van. A legjobb SSD optimális kihasználást illetően, az egyetlen partíció.
Viszont, ha megnézed ebben a bejegyzésemben lévő képet, akkor látod, hogy esetemben 2db partíció van csak, ahogy említettem."/boot" - Ami azért kell, mert kezelni szeretném az EFI bejegyzéseket egy titkosítatlan partíción és a grub.cfg-t is.
Ennek 1GB-ot hagytam, ami szerintem bőven elég, jelenleg is 20% használt csak. Régebben futottam bele abba, hogy 512MB kevés lett, mert 2 különböző kernel (linux, linux-zen) és akkoriban NVidia használat miatt a 2db initramfs-be bepakolt driver már nem fért el megfelelően. Így lett végül 1GB."/" - Ami pedig maga rendszer, tokkal-vonóval. Ez luks titkosított.
Anno nem érttem hogyan fog például az fstrim luks-on belül működni, de megcsinálja és jól csinálja (trimmed logból látszik)
Így tulajdonképpen ez a teljes ssd méret minusz 1GB területű partícióm.
De, mint említettem, ez csak egy lehetőség, ha valaki maga akar játszani a partíciókkal."Amúgy az overprovisioning nem jót tesz az SSD-nek, hanem alap a gyors és optimális működéséhez."
Oké, akkor pontosítok, nem jót tesz, hanem kell a megfelelő működéshez.
A 15% nem tudom honnét marad meg bennem, mint optimális érték, de végülis benne van az általad megadott tartományban. Nyilván a több, jobb.De mindez csak egylehetőség egy másmilyen felosztáshoz/használathoz, ha valaki mást akar, mint amit a telepítő default bedob.
De leülök magamtól.
-
válasz
.-..-.
#101918
üzenetére
És a fórumtárs írta, hogy: "Elkerülném most a next next next telepítést ubuntu telepítésnél"
Ez igaz, bár nem egyértelmű. Bár ha Linux Mint-et rak fel, azzal is elkerüli, legalábbis az Ubuntu telepítést. De lehet nem akar kezdőknek javallott módszert, akkor fenti mondatra az Ubuntu minimal.iso a megoldás(vagy fene tudja mi most a pontos megnevezése) vagy Debian netinst.iso...
Nincs ilyen-olyan partíciók miatt feleslegesen el nem érhető terület.
Épp akkor nincs szerintem, ha nincsenek külön particiók. A külön /boot lehet csapda ezek miatt: EFI, kernelek, initramfs, etc
Amúgy az overprovisioning nem jót tesz az SSD-nek, hanem alap a gyors és optimális működéséhez. Használati profiltól függően 7-28% a minimum amúgy. Felméri a rutinos user, mekkora meghajtóra lenne szüksége és kétszer akkora SSD-t vesz. Ez ilyen.
No de úgy látszik a next next next miatt, hogy totál feleslegesen írtam, offolom is magam, mielőtt megint valaki megint benyögi, hogy troll vagyok.
![;]](//cdn.rios.hu/dl/s/v1.gif)
Akit meg az SSD optimális használata érdekel, annak ott az SSD kibeszélő topik, várjuk szeretettel. -
...de nem szeretem, ha tul sok hely van parlagon.
Sajnos rossz hírem van, az SSD viszont kifejezetten szereti a szabad helyet! Mivel 512GB-ot írsz, azon egy deka gyárilag lefoglalt hely nincs, az overprovisioning miatt viszont minimum 7% szabad hely kell a meghajtón. Mennyivel jobb lenne, ha ez akár a rendszerpartició szabad helye lenne.
Megkérdezted, elég-e X GB hely a rendszernek. Ketten is írtuk, hogy nem, adj neki többet! Mégsem tetted.
Kérdeznék én is egyet:
Mi a ragyáért kérdezel rá egy szaktopikban egy konkrét dologra, ha utána sz*rsz a kapott válaszokra?
-
válasz
growler
#96547
üzenetére
Nem kifejezetten overprovisioning miatt maradt úgy, mivel értelmetlen külön olyat csinálni!
Ha megnézed, kifejezetten 50GiB és egy 220GiB méretű partició van, mert ilyen kerek értékeket akartam csinálni.
jó volt a beugratós kérdés
Érdekes ez a 0,87% EXT4 reserved méret is amúgy...szerencsére már rugalmasan kezeli ezt a rendszer, anno még 5% volt a reserved méret.
-
Már rég közel álltam a megoldáshoz, csak éppen háttal afelé! Amúgy bő egy éve már átestem, csak ott a notin volt Windows, a desktopon meg semmi, de valami miatt mindkettőn kellett csinálnom plusz EFI-t is. Most a legutóbbi Windowsos SSD mellé telepítéskor meg minden simán ment, nem kellett másik EFI...szóval emiatt is csináltam úgy, ahogyan a screenshoton van, először automata, utána manual particionálások...kialakul ez majd, mivel már lehetőség sincs legacy installra!
Ez az 1000 vagy 1024 SSD-nél is szökött gondot okozni a népeknél, sokan megdöbbenve írják, hogy az 1terás SSD-jük a OS szerint csak 931GB, ami ugye nem GB, hanem GiB, de még érdekesebb a helyzet a 960GB SSD-nél, mivel a NAND-ok méretét sehogy se adja ki ez az érték, de ha tudjuk, hogy ezeknél az eszközöknél alapból kivette a gyártó a méret megnevezéséből a 64GB overprovisioning-et, akkor minden tiszta lesz.
Én most ezt a DWPD calculatort nézegettem, de ez nem egy olyan mérőszám, amit lefordítasz TBW értékre, ugye valamilyen értékekkel a marketingeseknek is kell dobálózni.
Menjetek csak kaszálni, kertészkedni szépen! Itt Kóbambin szerencsére esik szépen.
-
Crvsh3R
senior tag
válasz
ubyegon2
#88904
üzenetére
Köszi az észrevételeke! Overprovisioning nincs beállítva (a másolás pillanatában 100+GB szabad hely volt rajta), ez egy 1TB-os meghajtó, WD Red SA500 NAS SATA SSD M.2 2280.
A kimenete a parancsnak:
smartctl 7.2 2020-12-30 r5155 [aarch64-linux-6.1.19-v8+] (local build)Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org=== START OF INFORMATION SECTION ===Model Family: WD Blue / Red / Green SSDsDevice Model: WDC WDS100T1R0B-68A4Z0Serial Number: XXXLU WWN Device Id: 5 001b44 8b128ad43Firmware Version: 411000WRUser Capacity: 1,000,204,886,016 bytes [1.00 TB]Sector Size: 512 bytes logical/physicalRotation Rate: Solid State DeviceForm Factor: M.2TRIM Command: Available, deterministic, zeroedDevice is: In smartctl database [for details use: -P show]ATA Version is: ACS-4 T13/BSR INCITS 529 revision 5SATA Version is: SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)Local Time is: Sun Mar 26 10:29:32 2023 CESTSMART support is: Available - device has SMART capability.SMART support is: EnabledAAM feature is: UnavailableAPM level is: 254 (maximum performance)Rd look-ahead is: EnabledWrite cache is: EnabledDSN feature is: UnavailableATA Security is: Disabled, NOT FROZEN [SEC1]Wt Cache Reorder: Unavailable=== START OF READ SMART DATA SECTION ===SMART overall-health self-assessment test result: PASSEDGeneral SMART Values:Offline data collection status: (0x00) Offline data collection activitywas never started.Auto Offline Data Collection: Disabled.Self-test execution status: ( 0) The previous self-test routine completedwithout error or no self-test has everbeen run.Total time to complete Offlinedata collection: ( 0) seconds.Offline data collectioncapabilities: (0x11) SMART execute Offline immediate.No Auto Offline data collection support.Suspend Offline collection upon newcommand.No Offline surface scan supported.Self-test supported.No Conveyance Self-test supported.No Selective Self-test supported.SMART capabilities: (0x0003) Saves SMART data before enteringpower-saving mode.Supports SMART auto save timer.Error logging capability: (0x01) Error logging supported.General Purpose Logging supported.Short self-test routinerecommended polling time: ( 2) minutes.Extended self-test routinerecommended polling time: ( 10) minutes.SMART Attributes Data Structure revision number: 4Vendor Specific SMART Attributes with Thresholds:ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE5 Reallocated_Sector_Ct -O--CK 100 100 --- - 09 Power_On_Hours -O--CK 100 100 --- - 1280412 Power_Cycle_Count -O--CK 100 100 --- - 337165 Block_Erase_Count -O--CK 100 100 --- - 53084803166 Minimum_PE_Cycles_TLC -O--CK 100 100 --- - 2167 Max_Bad_Blocks_per_Die -O--CK 100 100 --- - 180168 Maximum_PE_Cycles_TLC -O--CK 100 100 --- - 28169 Total_Bad_Blocks -O--CK 100 100 --- - 632170 Grown_Bad_Blocks -O--CK 100 100 --- - 0171 Program_Fail_Count -O--CK 100 100 --- - 0172 Erase_Fail_Count -O--CK 100 100 --- - 0173 Average_PE_Cycles_TLC -O--CK 100 100 --- - 9174 Unexpected_Power_Loss -O--CK 100 100 --- - 40184 End-to-End_Error -O--CK 100 100 --- - 0187 Reported_Uncorrect -O--CK 100 100 --- - 0188 Command_Timeout -O--CK 100 100 --- - 0194 Temperature_Celsius -O---K 056 074 --- - 44 (Min/Max 24/74)199 UDMA_CRC_Error_Count -O--CK 100 100 --- - 0230 Media_Wearout_Indicator -O--CK 001 001 --- - 0x0062005a0062232 Available_Reservd_Space PO--CK 100 100 004 - 100233 NAND_GB_Written_TLC -O--CK 100 100 --- - 9604234 NAND_GB_Written_SLC -O--CK 100 100 --- - 10046241 Host_Writes_GiB ----CK 253 253 --- - 9703242 Host_Reads_GiB ----CK 253 253 --- - 334267244 Temp_Throttle_Status -O--CK 000 100 --- - 0||||||_ K auto-keep|||||__ C event count||||___ R error rate|||____ S speed/performance||_____ O updated online|______ P prefailure warningGeneral Purpose Log Directory Version 1SMART Log Directory Version 1 [multi-sector log support]Address Access R/W Size Description0x00 GPL,SL R/O 1 Log Directory0x01 SL R/O 1 Summary SMART error log0x02 SL R/O 2 Comprehensive SMART error log0x03 GPL R/O 1 Ext. Comprehensive SMART error log0x04 GPL,SL R/O 8 Device Statistics log0x06 SL R/O 1 SMART self-test log0x07 GPL R/O 1 Extended self-test log0x10 GPL R/O 1 NCQ Command Error log0x11 GPL R/O 1 SATA Phy Event Counters log0x24 GPL R/O 1957 Current Device Internal Status Data log0x25 GPL R/O 1957 Saved Device Internal Status Data log0x30 GPL,SL R/O 9 IDENTIFY DEVICE data log0x80-0x9f GPL,SL R/W 16 Host vendor specific log0xde GPL VS 8 Device vendor specific logSMART Extended Comprehensive Error Log Version: 1 (1 sectors)No Errors LoggedSMART Extended Self-test Log Version: 1 (1 sectors)Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error# 1 Short offline Completed without error 00% 12668 -# 2 Short offline Completed without error 00% 6915 -Selective Self-tests/Logging not supportedSCT Commands not supportedDevice Statistics (GP Log 0x04)Page Offset Size Value Flags Description0x01 ===== = = === == General Statistics (rev 1) ==0x01 0x008 4 337 --- Lifetime Power-On Resets0x01 0x010 4 12804 --- Power-on Hours0x01 0x018 6 20348761502 --- Logical Sectors Written0x01 0x020 6 31058800 --- Number of Write Commands0x01 0x028 6 701009799064 --- Logical Sectors Read0x01 0x030 6 82441973566 --- Number of Read Commands0x07 ===== = = === == Solid State Device Statistics (rev 1) ==0x07 0x008 1 0 N-- Percentage Used Endurance Indicator|||_ C monitored condition met||__ D supports DSN|___ N normalized valuePending Defects log (GP Log 0x0c) not supportedSATA Phy Event Counters (GP Log 0x11)ID Size Value Description0x0001 4 0 Command failed due to ICRC error0x0002 4 0 R_ERR response for data FIS0x0005 4 0 R_ERR response for non-data FIS0x000a 4 1 Device-to-host register FISes sent due to a COMRESET
Néha le szoktam futtatni, rövid SMART teszt nem mutatott hibát. Elméletben 600TBW-s a meghajtó, annak még a közelében sincs. -
válasz
ubyegon2
#88904
üzenetére
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:
-
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/sdxA 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...
-
#88366
BoB
veterán
tordaitibi
#88364
BoB
veterán
válasz
tordaitibi
#88364
üzenetére
Kiegészítem amit agentswitch írt, szvsz kicsit félreérthető, bár lehet ez is az lesz.
az n1, az nvme0 után azt jelenti, hogy az első számú namespace. Ennek a mérete lehet akkora mint az egész eszköz, ebben az esetben nyilván csak ez az egy namespace lehet. Ez lehet kisebb is, de nem kötelező plusz namespace, ebben az esetben ez egy overprovisioning.
Illetve lehet több is, ezek az operációs rendszer számára olyanok mintha külön meghajtók lennének, ezekre írtam hogy afféle partícióként lehet rájuk tekinteni, de nem szabad azokkal keverni, mert az más. A namespace az SSD vezérlő szintjén kerül létrehozásra, annak a kezelése az OS számára transzparens, azaz az nem foglalkozik vele.
Tehát lehet "darabolni" vele az SSD-t, "több külön ssd-t létrehozni" ha úgy tetszik.
-
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. helpIgaz 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
-
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.
-
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.
-
válasz
Mustármag
#79816
üzenetére
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.....
-
válasz
Rimuru
#76389
üzenetére
Szerintem nincs, legalábbis ami itt említve lett, a sysvinit meg systemd. Mert szerinted van benne? DW-nél is ki van húzva az a sor. Kell egyébként egy webui-s valaminek init? (ehhez tényleg nem értek)
Persze ha lenne initrendszere annak a valaminek, akkor is pontosan ugyanezt javallanám a kollégának!
discard és/vagy garbage collection és overprovisioning
ennyi
-
válasz
Panthera
#76383
üzenetére
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ó discardopció 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.
-
válasz
vadkörte
#73738
üzenetére
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.
-
#71825
ubyegon2
félisten
Neil Watts
#71823
válasz
Neil Watts
#71823
üzenetére
journalctl | grep fstrimHa csinálsz egy gyors manual TRIM-et, annak is rakd be a kimenetét léci:
sudo fstrim -avMé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)
-
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/fstabparancs kimenetét.Archklónoknál,
discard,noatimeparamé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. -
válasz
szucstom
#71665
üzenetére
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.
-
válasz
anorche1
#71261
üzenetére
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. minimummikor 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!
-
válasz
Storms
#71255
üzenetére
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 -aparancs 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. -
válasz
Rimuru
#67743
üzenetére
/mediaa default, mint emlegettem már. És nem kényelmes, mert nem tudom milyen, Mint alatt nem foglalkoztam vele, csak az FSTAB-ba másoltam a szükséges sorokat.Igazatok lehet amúgy, Ubuntut nem használok, ha rosszul navigáltam a kollégát szerintetek, javítsatok ki ill segítsetek neki.
(megint kiderült, hogy jobb, ha nem írok semmit)Valójában már régóta nem is vauzok bele semmibe, most viszont SSD-s overprovisioning kérdés volt, emiatt nem bírtam megállni, de elég lett volna csak linkelnem a régi hsz-t.
-
Épp egy 500GB-os SSD példája van ebben a hsz-ben, az 5. ponthoz kiegészítésként linkelek, mivel erről már olvastam sokat. De mint szóba is került, akár ki is hagyhatod a swappal együtt a külön hely elkülönítését, a meglévő particiókon lévő szabad hely is ugyanúgy megfelel az SSD vezérlőjének.
A többihez jó szokásomhoz híven inkább nem mondok semmit, a rendszer elég ügyes, tud magának 6home-ot csinálni, külön ok nélkül értelmetlen azt is kreálni, de nem én vagyok itt a szaki.
-
válasz
Shyciii
#65932
üzenetére
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.
-
-
#65533
ubyegon2
félisten
ontheground
#65530
válasz
ontheground
#65530
üzenetére
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/PENDRIVEFirefoxot 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. -
Frawly
veterán
válasz
ubyegon2
#61558
üzenetére
Ja, erre nem is gondoltam. Sokan az OS-t hívják OP-nek.
De így már értem mit nem értettél. Az overprovisioning valóban nem TRIM-et használ. Közvetlenül a garbage collection sem használja. De ezeknek a munkáját segíti a TRIM, mivel ha egy LBA szektor vonatkozásában TRIM parancs érkezik, onnantól tudja a vezérlő, hogy törölhető a vonatkozó cellák tartalma, könnyebben kiüríthető az a NAND lap, amiben vannak ezek a cellák, és a felszabadult lappal dolgozhat a wear leveling (hasonlóan mint az overprovisioning cellákkal) meg a garbage collection is. Ezeknek az SSD-karbantartó mechanizmusoknak üres hely kell ugyanis, és a TRIM segít üres helyet csinálni. Ennyiben függnek össze.
A többiektől elnézést, valóban kezdő topik. De ennyi kitérő szerintem belefért, főleg, hogy nem én hoztam fel, és most 5-6 hozzászólás erejéig nem lett volna értelme egy másik topikba átmenni. Fele részben úgyis a swapról szólt, ami meg érintheti a kezdőket is.
-
Frawly
veterán
válasz
ubyegon2
#61555
üzenetére
120, 240 gigás SSD-knél is attól függ, hogy mennyire régi SSD, milyen hatékony garbage collection van beépítve. A régi SSD-k jobban rá voltak szorulva az overprovisioningre, főleg ilyen 32-128 GB méretben. A nagyobb SSD-k, de a 120 gigás újak is, már kevésbé kényesek erre, ott tényleg elég lehet az az overprovisioning terület, ami gyárilag el van különítve.
-
Frawly
veterán
válasz
ubyegon2
#61552
üzenetére
Igen, ezt hülyén írtam. Kimaradt egy szó: az overprovisioninggal nem kell PARTICIONÁLÁSKOR foglalkozni, hanem az SSD használatakor particionálás UTÁN arra kell figyelni...
Ugyanis sok olyan hülye tanács kering a neten, hogy az SSD-n hagyjunk nem particionált területet. Ez ugyan működhet is, de ha nagyon kell a hely pár óra, akkor nehezebb hasznosítani. Ezért én azt szoktam ajánlani, hogy ne legyne particionálatlan üres hely hagyva, vagy csak akkor, ha tudja magáról a user, hogy figyelmetlen, hajlamos tele pakolva felejteni a meghajtót, és/vagy lusta rajta állandóan helyet felszabadítani.
-
válasz
Frawly
#61551
üzenetére
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?
-
Frawly
veterán
válasz
ubyegon2
#61543
üzenetére
Nem szaktekintélykedünk. A swap partíció pont hogy elveszi a területet az overprovisioning elől. Igaz a swap fájl is, szóval ha swapról van szó, ezt nem lehet megúszni, a swap nem TRIM-elhető. 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, hogy 10-20% szabad hely legyen rajta. Persze nem gond, ha néha teljesen betelik, de nem szabad úgy hagyni, hanem csinálni kell rajta helyet, hogy legyen rendszeresen szabadon.
A 16 GB swap-ot ne ajánlgassuk már 8 GB RAM mellé. Majdnem biztos vagyok benne, hogy átlagos felhasználásról van szó, és az a 8 GB-os swap partíció is abszolút overkill, amit létrehozott. Ez a swap legyen a duplája a fizikai RAM-nak mantra, még az ősrégi windowsos időkből való, mikor még 64-256 MB RAM volt egy átlag gépben.
Egyébként nem vagyok teljesen a swap partíció ellen sem, ha már később lesz hosszú távú tapasztalata Linux-témában, akkor már tudni fogja mekkora swap kell neki az adott RAM mennyiség mellé az ő felhasználásához, úgy már mindegy, hogy swapfájl vagy swappartíció van, úgyse kell a méretét igazgatni.
(#61550) vargalex: szerintem már egy mai modern Atom/Celeron N procis gépen is mérhetetlen, főleg, ha SSD-ről fut.
-
válasz
Frawly
#61542
üzenetére
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
zrammé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] -
válasz
growler
#52760
üzenetére
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.
-
válasz
Zola007
#44582
üzenetére
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 -
#44061
ubyegon2
félisten
Atlantisz48
#44057
válasz
Atlantisz48
#44057
üzenetére
É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 -
válasz
kkdesign
#41797
üzenetére
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.
-
válasz
kkdesign
#41185
üzenetére
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!
-
válasz
ubyegon2
#41182
üzenetére
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.
-
válasz
whbear
#40215
üzenetére
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!
-
válasz
Rimuru
#35424
üzenetére
Én inkább maradok a kérdéseknél, nem vagyok még közel sem azon a definitív szinten, hogy definiáljak bármit is! (ez mekkora megfogalmazás, akár kötélrevaló politikusnak is mehettem volna) SSD overprovisioning, hát ez pont rossz 5let volt tőlem
, mert a pontos fogalom az ok, de az optimális használata/beállítása a gurukat is megosztja. Pedig pont ez lenne a lényege.
Ha a gépem nem omlik össze táphiba miatt, akkor ilyen SSD/Linux fogalmakat megpróbálok összeollózni, bár van ennek is topikguruja, berus.berus. -
válasz
Nestor16
#33221
üzenetére
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.
Nyilván akkor érvényesek ezek a megállapítások, ha relatíve kevés hely van a meghajtón ill emellett kevés az overprovisioning is! Egyébként home usernek bőven elég a beállított ütemezett TRIM is a default heti ütemezéssel, de ezt is át lehet állítani napi lefutásra, ha szükséges.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Akit meg az SSD optimális használata érdekel, annak ott az SSD kibeszélő topik, várjuk szeretettel.
De ahogy nézem, ebben a topikban is toltam rendesen az 
, 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ó 
(megint kiderült, hogy jobb, ha nem írok semmit)
Szerencse, hogy a múltkor nem töröltem .
Új hozzászólás Aktív témák
CPT.PirkA topik célja: Segítségnyújtás a Linux disztribúciókkal még csak ismerkedők számára. A szerveres kérdések nem ebbe a topicba tartoznak.
Kérdés előtt olvasd el a topik összefoglalóját!
Haladó Linuxos kérdések topikja.
Linux felhasználók OFF topikja
Milyen program ami... [link]
Shell script kérdésekkel látogassatok el a topikjába
- Vélemény Ubuntu 20.04 LTS
- Vélemény Linux Mint Debian Edition 4
- Tudástár MX-Linux 19
- Bemutató Linux a mindennapokban: Manjaro KDE
- Bemutató Linux a mindennapokban
- Hír Zöld utat adott a nyílt forráskódú Linux meghajtóknak az NVIDIA
- Hír A Steam Play hozza el a Windowsra írt játékokat Linuxra
- Hír Hova jut a világ? Linuxot kínál a Windows Store!
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- Bambu Lab 3D nyomtatók
- Vezetékes FEJhallgatók
- Samsung Galaxy Z Fold5 - toldozás-foldozás
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Milyen billentyűzetet vegyek?
- A fociról könnyedén, egy baráti társaságban
- Háztartási gépek
- Békéscsaba és környéke adok-veszek-beszélgetek
- További aktív témák...
- Vírusirtó, Antivirus, VPN kulcsok
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - NYÁRI AKCIÓ!
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- ÁRGARANCIA!Épített KomPhone i5 10600KF 16/32/64GB RAM RX 6600 8GB GAMER PC termékbeszámítással
- Apple iPhone 16 Pro Max - Desert Titanium - 256GB 1 ciklus 100% akku! 1 év garancia! Új készülék!
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- Apple MacBook Air Megbízható társ a mindennapokra!
- Xiaomi 14 512GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest