Keresés

Hirdetés

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

  • janos666

    nagyúr

    LOGOUT blog

    válasz Fire/SOUL/CD #14819 üzenetére

    Jobb -> Igen, mert rugalmasabban kezelhető és EFI módban bootolható
    Gyorsabb -> Csak áttétesen: EFI módban gyorsabb lehet a boot
    Biztonságosabb -> Egy hajszállal a saját backup-ja miatt (bár nem látom értelmét)

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz p.lac #14838 üzenetére

    Szerintem van rá magyarázat. Az újraírás segít "töredezettségmentesíteni".

    A vezérlő több érthető okból is próbálja elkerüli azt, hogy saját szakállára írjon a NAND-ra, így alapvetően akkor ütyködik, mikor a SATA felől is kérnek tőle írást (kivéve, ha már muszály neki). Az új írásokat próbálja úgy végezni, hogy (fél/)passzívan elvégezze vele közben a "töredezettségmentesítést" is.
    Ha így írsz rá (viszonylag nagy blokkokban, szekvenciális jelleggel), akkor közben kedvezőbben rendezi magát újra, mint ahogy korábban véletlenszerűen alakult (ha pl. OS van rajta).
    Ez a "refresh" szekvenciális jellegű, a normál használat pedig részben random. A szekvenciális írás "töredezettségmentesíthet" (vagy legalább eleve nem tördel), a random "tördelhet" (mikor mennyire, de úgy általánosságban, előfordulhat, ha van időnként sok apró írás).

    Na meg SandForce-nál még tovább "tördelhet" a tömörítés is.
    Úgy sejtem, hogy ehhez van köze annak, hogy a TRIM sem mindig éri el teljesen a várt hatást (ezeken a SandForce-okon), az ilyen "refresh" (mint a backup-restore is, főleg ha közben SE-t is kap) viszont igen.

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz p.lac #14838 üzenetére

    Ja, az a rész el is kerülte a figyelmem, hogy lassult a maximális olvasás, csak "nagy okosan" megmagyaráztam az érthető jelenséget. :Y
    Bocs. :B

    Na, erre nem nagyon van ötletem.

    Annyi vak tippem lenne, hogy mikor egy ilyen kvázi-folytonos és statikus elméleti felső korláttal is bíró folyamatban nő az átlag és csökken az ettől negatív irányba történő kilengés momentuma is, akkor ha nem is törvényszerű, de normálisnak tűnik, hogy csökken a pozitív irányba történő lengésé is (nincs olyasmi, hogy amikor "megbotlik" valamiben az egyik "keze", akkor közben a másikkal előre dolgozik egy bufferbe, amit aztán az elvi maximális sebességen tud továbbdobni, mielőtt ismét az átlaghoz kezd konvergálni ott, ahol nincs annyi kátyú az úton).
    -> Ugyanakkor a particionálatlan LBA terület méréseire nagyon passzol ez az elmélet.

    Egy másik vak tipp, hogy eddig ugye sohasem használtad a particionálatlan terület LBA szektorait, most viszont igen (akkor is, ha csupa nullát olvasott ki és írt vissza a diskfresh program).

    Szóval ... izé ... talán épp most bizonyítottad be ezzel a teszttel, hogy még a tömörítős SandForce vezérlőnek sem mindegy, hogy TRIM-elve van-e a partíció/filrendszer szinten üres LBA terület, még akkor sem, ha ott minden LBA csupa nullákkal van tele (de még sincs törölhetőnek jelölve TRIM-el). :C

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz p.lac #14847 üzenetére

    Ha tesztelni szeretnél, engem jobban érdekelne, hogy:
    - most futtatsz egy olvasási tesztet
    - Live Linux-ból blkdiscard-al TRIM-eled a particionálatlan területet (legegyszerűbb, ha felraksz egy átmeneti particiót, TRIM-eled a RAW particiót, aztán törlöd -> sőt, ezt igazából Windows-ból is megteheted: create partition, format quick, assign, defrag e: /L , delete partition).
    - megismétled az olvasási tesztet

    Bár megint SandForce... nem biztos, hogy úgy reagál a TRIM-re, mint a legtöbb SSD vezérlő, szóval szerintem nem változna semmi.

    Következőben pedig hagynám a refresher-t, helyette
    - készítenék egy backup-ot (de a file-okról, nem a nyers szektorokról + MBR-t, vagyis az első blokk DD-vel)
    - secure erase
    - restore (MBR DD-s visszaállítása után a file-ok visszamásolása, pl egy-egy TAR file-ból kibontva)
    - új olvasás teszt

    Amúgy...
    "beáldozok mindjárt még kb. 55GB-nyi írást"
    Vigyázz, mielőtt terroristának bélyegeznek az ilyesmikért. :DDD

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz p.lac #14850 üzenetére

    Úgy látom gyorsabban szülted meg a parancsot, mint hogy begépeltem az alternatívát. :D Igen. Érdekelne. (Olvasás blkdiscard előtt és után).

    Aztán esetleg a másik, amit írtam, de ebben a sorrendben, és a második teszt csak úgy, ha a diskrefresh helyett csinálod, a kedvemért ne nyúzd.

    Hmm... Ha nem egy HDD-n lévő VHD-ban lenne egy dísznek tartott Linux-om, akkor pont tele lenne a 128Gb-os SSD-m.

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Doky586 #14878 üzenetére

    TRIM és csupa nulla...

    Igen, közben már beismertem és azóta arra is rájöttem, hogy mi volt a félreértés:

    Egyszer, mikor nagyon csúnyán belassult a 840 Pro SSD-m, akkor látványosan segített neki az, hogy tesztképp végigírtam nullákkal. Ez volt a saját egyéni tapasztalatom így a TRIM generációval is, és korábban a TRIM korszak előtti SSD-kről is olvastam hasonlót, hogy volt, akinek ez segített (nekem is volt már SSD-m a TRIM előtti időkben is, de nem érdekeltek ennyire és általában meg is döglöttek, mire betömődtek, így nem volt velük hosszabb távú tapasztalatom, főleg nem az ilyen problémák kezelésében. :))).

    De tény az is, hogy alapvetően később terjedt el az automatikus hardware-es titkosítás, mint a TRIM.

    --- Szóval ez úgy kezdődött, hogy marha lassú lett a 840 Pro, elkezdtem tesztelni, végül írással is, majd egy faltól-falig történő zerofill-el bezárva, amit hagytam végigfutni, mikor láttam, hogy induláskor az is nagyon lassan megy neki, viszont ahogy fut, úgy egyre csak gyorsul. Végól pedig adtam neki egy második kör zerofill-t, ami alatt egyértelműen gyorsabb volt, mint először, így sikeresnek nyilvánítottam a kísérletet. ---
    Akkor ez számomra még rejtély volt, hogy mi történt előtte-közben-utána. Ezt követően frissítettem az SSD firmware-t és Secure Erase-t is adtam neki, azóta pedig nem volt vele hasonló probléma.

    Ma úgy sejtem, hogy a megoldás abban rejlett, hogy a szekvenciális írás || legyen az akár csupa egyes vagy nulla, netán véletlenszerű byte-ok, a lényeg, hogy nagy blokkokban írjunk az SSD-re || "töredezettségmentesíti" az SSD-t, amit a véletlenszerű kis írások "tördelhetnek" (ami ott és akkor valahogy nálam ténylegesen is bekövetkezett ; talán OS oldalon volt hiba, talán firmware oldalon, talán a kettő együtt okozott gondot, ezt nem tudom biztosan).

    -> Innen volt az a tapasztalatom, hogy segít a zerofill.
    ---> De!!! Deee!!! Egyébként tényleg segített is a maga módján!
    Az már egy másik kérdés, hogy arra a problémára sem ez volt a legjobb megoldás és hogy kicsit összekeveredett a dolog, mert nem ugyan azt éri el, mint a TRIM. Az az én téves feltételezésem volt, hogy van olyan okos az SSD vezérlő, hogy ha pl. 2Mb egy Erase blokk és valaki felír 2Mb-nyi nullát, akkor az SSD vezérlő odabent "töredezettségmentesítés" után töröl egy Erase Blokk-ot, de erre nagyon jól rámutattál, hogy a belső titkosítás miatt ez nem ilyen egyszerű és valószínűleg nem történik meg. Lehetne ilyen okos a vezérlő, kereshetné és a NAND-on egymás mellé mozgathatná a csupa nulla LBA-kat, hogy törölhesse a blokkot, csak épp titkosítva már nem nulla a nulla. Teljesen igazad volt. :R

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Soma01 #14885 üzenetére

    A legbiztosabb tipp szerintem az, ha nem bírálod felül a beállítást, hanem Auto-n hagyod. Én szeretek piszkálni mindent, de egy ideje visszatértem a pagefile-al az auto beállításra, mert kézileg vagy feleslegesen sokat hagyok meg előre (általában 4Gb-ot hagytam mindig, akár SSD, akár HDD, csak akkor próbálkoztam kevesebbel, mikor kissebb SSD-m volt), vagy csak idő kérdése, hogy egyszer elszálljon egy program (annyit pedig nekem nem ér az, ha pár száz Mb-al, netán 1Gb-al is többet foglal le automatikusan, mint ahova én spórlósan tenném, most épp 2.37Gb-on áll magától, 1Gb alá pedig próbaképp sem mennék és fix 2-ben bíznék, hogy "soha" nem kéne nagyobb).

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz varmi2 #14909 üzenetére

    Ha egyetlen nagy MBR particio lesz, akkor csak az alapértelmezett 4k-val (vagy kisebbel) formázhatod, mert a BIOS-os bootloader ezt követeli, csak ezt fogadja el a telepítő.
    Ha MBR-en lesz egy külön kis boot partició a boot loader-nel (ilyenkor azt hiszem van egy minimális méret, 100 vagy 200Mb, amit elfogad a telepítő), akkor elég azt 4k-val formázni, a mellette lévő nagyobb particio már tetszés szerinti (4k-tól nagyobb is lehet --- kisebb bármelyik bármikor).
    Ilyenkor (MBR) alapvetően mindennek NTFS-nek kell lenni (ha van külön boot particio, akkor talán az lehet FAT is, de nem hiszem, mert épp a bootloader kényes arra, hogy 512 byte és 4k közt legyen az NTFS unit size, ne legyen nagyobb, szóval gondolom az NFTS is kötött, de még nem próbáltam).

    Ha GPT particio lesz (én Win8.1 alá UEFI-s alaplappal ezt javaslom), akkor mindenképp kell egy kis EFI partició (ez kisebb is lehet, mint az MBR-es boot particio, nem nézi olyan szigorúan, csak férjen el rajta a bootloader) a nagyobb particio mellé, viszont mindkettőt olyan allocation unit-al formázod, amilyennek csak szeretnéd (illetve amit megenged az adott filerendszer adott partitio méret mellé).
    Ilyenkor az EFI mindenképp FAT (FAT=FAT16 vagy FAT32), a rendszer pedig NTFS (még a Win10 TP sem települ ReFS-re, a FAT pedig amúgy se lenne ajánlott a nagy particióra, még akkor sem, ha elfogadná a telepítő és boot-olna róla a rendszer, de szerintem nem is fogadja el).

    A fenti kötöttségek mellett a unit size-ról te döntesz saját belátásod szerint. A kisebbnek és a nagyobb mögé is lehet érveket felsorakoztatni.

    Én legutóbb így particionáltam:

    diskpart
    list disk
    select disk 0 (értelem szerint a listából 0-x az SSD-d száma, pl. méret alapján)
    clean (!->ez töröl mindent, szóval előbb ments le bármit, amit szeretnél<-!)
    convert gpt
    create partition efi size=32 offset=1024
    select partition 1
    format quick fs=fat unit=8192
    create partition primary
    select partition 2
    format quick fs=ntfs unit=8192
    exit

    De nem igazán vettem észre előnyét a 8k-nak.
    Olyan szempontból, hogy a filerendszerben üres AU-k alatti LBA-kat TRIM-eli a Windows, jobb a kisebb AU. Ilyen oldalról az 512 byte lenne ideális (1 AU = 1 LBA), ugyanakkor a 4k alatti AU méretnek már érdembeli negatív hatása van. A magasabb inkább a szekvenciális műveletekhez jobb, illetve nálam a 8k az pont passzol a NAND flash Page Size-hoz, viszont nem vettem észre érdembeli javulást 4k-ról 8k-ra lépve.

    Szóval... legközelebb szerintem visszatérek majd 8k-ról 4k-ra.
    De a többi működik (32Mb-os EFI particio FAT-al + maradék nagy particio NTFS-es, csak az AU-t cserélném ki 4k-ra, ha ma megint telepítenék).

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Sk8erPeter #14915 üzenetére

    Hát a GUI-t tényleg nem próbáltam ki, csak a DISKPART-ot, mert a GUI némileg egy "fekete doboz" ahhoz képest, így nehezebb / bizonytalanabb egy hasonló alapossággal végzett teszt, én pedig alapvetően csak egy gyorstesztet szerettem volna végezni múltkor. (Valamint első körben feltételezném, hogy a GUI mögött is a DISKPART fut, bár egyáltalán nem biztos.) Na meg legtöbben amúgy is telepítéskor particionálnak (kézileg vagy automatikusan), nem előre egy működő Windows alól. -> Igaz, az automata telepítős GUI-t sem teszteltem le, csakis a DISKPART-ot.

    Lehet, hogy akkor ráfogom a dolgot és megnézem a GUI-t is, mert legutóbb ezt és egy alaposabb 4k vs. 8k tesztet is egy Intel (X25-M vezérlős) SSD-vel végeztem (egy olyan volt szabadon), és a 4k-8k érdekelne még a Samsung 840 Pro-val is (amit végül is csináltam, de csak úgy, hogy előtte és utána is arról futott egy Windows, ami véletlenül is belepiszkálhat a mérésbe + nem pontosan ugyan úgy volt megtöltve/szabadon különböző programok file-jaival, ami szintén sokat számít, valószínűleg többet, mint hogy 4k vagy 8k).

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Doky586 #14916 üzenetére

    De egyrészt, amennyire én tudom (de javítsatok ki, ha tévedek - én elismerem, hogy előfordul) a legtöbb SSD nem 4k, hanem 8k "szektoros", mert 8k szokott lenni egy NAND Page (ami ha jól tudom azt jelenti, hogy ekkora egységekben írhat a vezérlő a NAND-ra, a 4k írást is vagy úgy oldja meg, hogy kiolvas 8k-t és visszaírja 4k-val módosítva, vagy alternatívaként összevár több 4k-s írást, mikor "ráér" és elfér a cache-ben).

    Másrészt pedig sok SSD a fizikai és logikai szektorméretet is 512 byte-nak jelenti, egyiket sem 4k-nak vagy 8k-nak, és így a Windows nem is nagyon tudhatja, hogy mekkora egy NAND Page (hacsak nincs valami más módszer, amit erre használ, de olyanról még nem hallottam).

    Harmadrészt pedig akkor is az a lényeg, hogy a SATA3 szabványban LBA-kat lehet TRIM-elni, méghozzá azokat az LBA-kat, amiket az SSD mutat az OS felé, azok pedig bizony legtöbbször 512 byte-osak (az teljesen más kérdés, hogy az SSD-n belül mi van, az OS így látja és így kommunikál, ha ezt mutatja neki az SSD).

    Negyedrészt, ha össze tud fűzni 2x4k-t a cache-ben, akkor illene hogy 16x512byte-ot is össze tudjon. De legalább is nem lehetetlen feltevés, hogy lehetséges az ilyen. Annyit megért, hogy egyszer mértem így is (512 byte-os AU-val). És szerintem nem is az a gond, hogy ne tudná összefűzni a cache-ben, hanem hogy bizonyos nézőpontból szemlélve gyakorlatilag 8x annyi IOPS-t kéne kitolni izomból, ami szekvenciális műveletnél nem gond, de random 4k tesztnél igen -> ugyan is pont ezt mértem le, hogy a szekvenciális tesztet nem befolyásolja a szektorméret, csak a random 4k-t. Felteszem azért, mert nem képes a SATA és/vagy SSD vezérlő végtelen sok IOPS-re. -> De ez meg valószínűleg csak szintetikus tesztben számít és fogadnék, hogy nem nőne gyorsabban a Wear Leveling számlálóm hétköznapi használat közben, ha 512byte-al formáznám a C:-n az NTFS-t. De ha érdekel, akkor szívesen kipróbálom (engem érdekel egy kicsit, de annyira nem, hogy magamnak kipróbáljam).

    Ezért ötlött fel bennem, hogy ki lehetne próbálni 8k NFTS-el formázni a Windows particióját (így nem a vezérlőnek kell odabent játszogatnia azzal, hogy olvas-módosít-ír, vagy összevár 2x4k-t a cache-ben).

    De mivel két különböző SSD tesztelése után azt láttam, hogy nincs érdemi különbség szintetikus tesztekben, így most inkább vagyok azon a véleményen, hogy többet ér akkor inkább 4k-n hagyni, pontosabban kár vele foglalkozni, hogy átállítsuk 4k-ról (aminek megvannak a maga megszorításai, hogy mikor minként lehet). Elég nagy és gyors az a SoC-on belüli cache, illetve úgyis ott van benne több ARM CPU mag (SSD vezérlő), nem kell félteni, feltalálja magát 4k-s és 8k szektormérettel is.

    Az itt közölt hozzászólás magánvélemény. A tévedés jogát fenntartom. Az esetlegesen ebből fakadó károkért felelősséget nem vállalok.)

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Sk8erPeter #14921 üzenetére

    Az is a telepítő GUI-val particionál, aki statikus over-prosvisioning területt hagy?
    Ja, tényleg....
    Én azt még nem is nagyon használtam. Vagyis tudom mit csinál akkor, ha csak az eszközt jelölöd ki ([EFI], MSR, Recovery, maradék és hasonló sablonok), de "félautomata" módban, hogy te adod meg a méreteket ott abban a kis alsó sávban, ami előjön, ha rálépsz... Na, ez ki is ment a fejemből, hogy ilyen is van és így is lehet over-provisioning területet hagyni. :))

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Sk8erPeter #14924 üzenetére

    Ez egy 2010-es cikk. Akkoriban még az SLC-k domináltak. Én a ma legszélesebb körben elterjed MLC-s SSD-kre gondoltam.

    Itt egy példa miként nőtt az Intel-Micron NAND Page mérete az évek során:
    http://www.anandtech.com/show/7147/micron-announces-16nm-128gb-mlc-nand-ssds-in-2014

    Egy másik táblázat a Samsung NAND lapkáiról (+ néhány Intel-Micron ismétlés):
    http://www.anandtech.com/show/7173/samsung-ssd-840-evo-review-120gb-250gb-500gb-750gb-1tb-models-tested

    Tehát az utóbbi években 4k-ról 16k-ra nőtt a legnépszerűbb SSD-kben használt NAND flash memóriák Page mérete, ami két dolgot jelent: ma valószínűleg 8k-s a legtöbb aktív, otthoni felhasználásban lévő SSD (ezért írtam ezt az értéket), látjuk, hogy SSD-nként többféle lehet (legalább három féle létezik a közismert SSD-k közt, összesen talán még több, továbbá ahogy telnek az évek, talán még több méret lesz jelen, ha felszalad 32k-ra, pl. az olcsó TLC vagy netán QLC NAND-ok Page mérete).

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Sk8erPeter #14926 üzenetére

    Nyugi, megszoktam már, hogy ebben a topicban akkor sincs igazam, ha mégis. ;]

    Ha a Samsung maradt volna inkább 21nm-es (vagy akár 19nm-es) csíkszélességen ahelyett, hogy visszaugrik 40nm-re, de ezzel párhuzamosan MLC helyett SLC konfigurációra optimalizálta volna a 850 Pro alapját képező V-NAND lapkáit (valószínűleg így is nőhetett volna, de legalább is nem lett volna rosszabb a névlegesen "garantált" írási ciklusok száma a 20nm-es MLC-hez képest, miközben a négyzetes területszámítás szabályai alapján még kisebbek is lehettek volna a lapkák) és ez kijött volna egy hasonló árszabásból, akkor szerintem csak úgy a hecc kedvéért is lecseréltem volna a 840 Pro-t (így viszont eszemben sincs, inkább cserélnék 256Gb-os 840 Pro-ra, amin több szabad helyet tudnék hagyni, így még gyorsabb is lenne, mint egy 128Gb-os 840 Pro, csak ott lenne a terület is tartalékba, ha néha kell átmenetileg valami váratlan dolognak).

    Nem tudom, hogy a Samsung-nak ez miért nem jutott eszébe, mert az apró szeletes random írás/olvasás-t valószínűleg megdobhatta volna kicsit, a szekvenciális írás/olvasás pedig már amúgy is ki volt lőve a SATA3 határára, tehát ott amúgy sem nagyon volt hova tovább, ha ettől féltek, hogy lentebb nem szabadna. Mert amúgy meg megy V-NAND enterprise termékekbe is. :U

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz p.lac #14928 üzenetére

    Nem kötekedésnek veszem, hanem lustaságnak, mert erre is úgy fogok válaszolni, hogy beszúrom a top5 google találatok közül azt a kettőt, ami első ránézésre a legrelevánsabbnak tűnik. :P :P :P

    Ez a második google találat a micron.com-ról, vagyis "közvetlenül a ló szájából", ahogy az angolszász szerzője mondhatná (már ha valamiért lónak szeretné magát nevezni):

    http://www.micron.com/-/media/documents/products/technical%20marketing%20brief/ssd_effect_data_placement_writes_tech_brief.pdf

    Ahol is ez olvasható:

    Page is the smallest unit of storage that can be written to, typically 4K or 8K."

    De az első találat sem rossz:

    http://codecapsule.com/2014/02/12/coding-for-ssds-part-2-architecture-of-an-ssd-and-benchmarking/

    "Cells are grouped into a grid, called a block, and blocks are grouped into planes. The smallest unit through which a block can be read or written is a page. Pages cannot be erased individually, only whole blocks can be erased. The size of a NAND-flash page size can vary, and most drive have pages of size 2 KB, 4 KB, 8 KB or 16 KB. Most SSDs have blocks of 128 or 256 pages, which means that the size of a block can vary between 256 KB and 4 MB. For example, the Samsung SSD 840 EVO has blocks of size 2048 KB, and each block contains 256 pages of 8 KB each."

    Az a pár Mb-os Erase Block, ami pár száz Page-ből áll, az szó szerint Erase Block, vagyis egy-egy ilyen blokk törölhető egyszerre. De az írás Page-enként történik.

    De eleve csak gondolj be abba, hogy mennyire beb@szna, ha pl. a szintetikus random 4k írás teszt minden IOPS-ra 1-2Mb írást generálna az SSD-n belül. Futtatnád a sok tízezer IOPS-t generáló tesztedet, aztán hirtelen azon kapnád magad, hogy elhasználtál több tucat P/E ciklust (és valószínáleg tapinthatóan meleg az SSD pár perc után ;]).
    Egy nap alatt ki lehetne így nyírni egy 840 EVO-t (P/E ciklus elkoptatással vagy túlmelegedéssel), ha ez így működne, nem? ;]

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz janos666 #14929 üzenetére

    Jó, mondjuk az SSD gyilkosságon enyhít, ha van mondjuk ~256K cache a vezérlőben (az Intel X25-M vezérlőről találtam ilyen konkrét adatot), így nem 4k-nként írna fel 2Mb-os blokkokat, hanem 256k-nként, de még akkor is tízszer több írás fárasztaná a NAND-ot, mint ami a SATA-n átmegy (vagy többször, ha nem tökéletes a cache-elés, vagy eleve nem hagyja, hogy teljesen megteljen a cache, mielőtt írni kezd...). Az is sok.

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz p.lac #14937 üzenetére

    Bocs, először azt hittem, hogy a cikkből kimásolt szöveg van ellentmondásban önmagával, de félreértettem (pontosabban én először nem is vettem figyelembe azt a rész, mert nem tűnt közvetlen módon relevánsnak a saját kijelentéseimre nézve, csak akkor gondolkodtam el rajta, mikor kiemelted benne ezt a rész):

    "Az SSD csak üres lap(ok)ra (4 kB-os egységek) írhatja fel az új adatokat, az érvénytelen adatokat tartalmazó lapok pedig ottmaradnak a helyükön, amíg szükség nem lesz a szabad területre. Ráadásul létezik még egy korlátozás, ami további problémát jelent: az SSD csak egy komplett blokk (512 kB, azaz 128 darab 4 kB-os lap) törlésére vagy felülírására képes."

    Itt a FELÜLírás a kulcsszó.
    Írni csak üres Page-re tudunk, üres Page-t pedig csak Erase Block törléssel tudunk csinálni. Ez nem jelenti azt, hogy minden Page felírásakor törölni kell egy Erase Block-ot, hogy legyen üres Page-ünk, mert általában lehet találni eleve üres Page-t is, ha TRIM-elünk és nem pakoljuk koppig az SSD-t (úgy, hogy még a host elől rejtett rész is dugig tömődjön). A felülírás viszont kifejezi, hogy a Page, amit módosítani szeretnénk, az nem üres. Ilyen esetben pedig csak úgy lesz üres az a felülírni kívánt Page, ha a teljes Erase Block-ot töröljük, amihez az a felülírni kívánt Page tartozik. Tehát ilyenkor kénytelenek vagyunk akár olyat is csinálni, hogy olvas-módosít-töröl-ír (jó lassan) egy egész Erase Block-on.

    De most segítséget kérek, hogy ez miként áll ellentmondással azzal, amit eredetileg írtam (figyelembe véve azt is, hogy TRIM-elünk, mert mostanság az a megszokott), mert bevallom, hogy ezzel most már talán elvesztettem a fonalat. :DDD

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz p.lac #14941 üzenetére

    "Vagyis nem olvas-módosít-töröl-ír, hanem olvas(A blokkot)-ír(B blokkba az A blokkból az érvényes page-eket)-töröl(A blokkot)."

    Ha tovább bonyolítjuk a kérdést a GC-vel, akkor igen.
    De megint idézem és pingálom az eredeti mondatom:

    "Tehát ilyenkor kénytelenek vagyunk akár olyat is csinálni, hogy olvas-módosít-töröl-ír."

    Szerintem ez a mondat sem azt fejezi ki, hogy ez lenne a leggyakrabban, mértékadó helyzetben, vagy akár csak sűrűn előforduló eset, hanem egy bizonyos (még a 2010-es cikkből idézett szövegben felvetett) lehetséges felállás.
    (Sőt, igazából még az is lehet, hogy a cikk szerzője egyszerűen hibázott | akár félreértett akkoriban valamit, vagy rosszul sikerült megfogalmaznia a gondolatait és a mondata mást jelent, mint amire gondolt | és most csak mi magyaráztuk meg, hogy igazából úgy is igaza van. Bárkivel bármikor megeshet. De ennyire messzire talán már tényleg ne menjünk. :)))

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz FollowTheORI #14959 üzenetére

    Tudom, szeretem ezeket a teszteket, sokkal érdekesebbek, mint az üres, frissen formázott SSD-k Crystal Disk Mark képei. Az Anandtech szokott rajzolni szép grafikonokat az ilyen stress tesztekről.

    A biztonság kedvéért még egyszer utoljára:
    -> egy 2010-es cikkből származó idézetből ágaztunk le erre a téma szálra.
    1: Akkoriban még nem volt túl elterjedt a TRIM. Windows-on pl. 2009 októbere óta van + akkor még nem volt ez minden SSD-nél alapvető tudás, az öregebbek cunsumer példányok esetleg firmware frissítés révén kapták meg valamikor, ha egyáltalán (valamikor 2009-2010 közt, esetleg késve, vagy a "budget" inkább soha).
    2: Gondolom, hogy akkoriban még a GC algoritmusok sem voltak annyira a toppon, mint manapság (pl. nekem is volt "lagolós" SSD-m még a TRIM előtti időben ; pár napig nagyon jó volt a "drágaság", de később ha írni kellett, néha lassabb volt, mint egy HDD, ekkor jött egy backup-zerofill-restore ||mert a Secure Erase-t még nem ismertem|| aztán megint jó volt, majd pár ilyen hét után kuka :DDD).

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz M^xx #14961 üzenetére

    Az SSD-nek biztos nem kell driver (és nincs is, nem találsz ilyet).
    Esetleg a SATA vezérlőnek kellhet. De annak sem szabadna gondot okozni (fel kéne ismernie a Windows-nak az ISO-ban mellékelt driver-ekkel a hétköznapi szokásos vezérlőket).

    Esetleg valamilyen PCI-E bővítőkártyára, vagy valami olyan SATA portra van kötve az SSD, ami egy külön alaplapra integrált PCI-E vezérlőből és nem az Intel vagy AMD chipsetből származik?

    Amúgy pedig Vista felett, ha nincs valami speciális igényed és/vagy nem értesz hozzá és vagy maximalista, akkor ne hozz létre partíciót, hanem bízd a telepítőre: törölj minden partíciót a lemezről és jelöld ki magát a lemezt, mint telepítési cél, aztán tovább-tovább, majd ő szétosztja a helyet, ahogy ő szereti.

    Ha Windows XP, akkor ott a gond. Az nem fog felismerni semmi SATA vezérlőt floppy nélkül, csak ha előre belefőzöd a telepítőbe.

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz M^xx #14966 üzenetére

    Írtam is rá javaslatot, hogy törölj minden partíciót a 0. lemezről és utána jelöld ki a szabad területet, hogy ő hozzon létre partíciókat...

    ---

    Más: ha már nekimentünk, most próbálom alaposabban tesztelgetni az NTFS AU hatását, ezúttal olyan formában, hogy a 128Gb-os 840 Pro-n minden LBA-t megtömtem adattal, és csak egy 128Mb-os kis partíción tesztelek random írással (itt váltogatom az AU-t anélkül, hogy újra fel kéne írnom ~127Gb adatot a többi LBA-ra, amit TRIM-elne formázáskor).

    Nincs még sok adat és főleg nem kiértékelés, viszont most nagyon tetszik, hogy egyszerűen nem hajlandó lehasalni ilyen körülmények közt a 840 Pro. Ezzel az xx6xx-os firmware-el hihetetlen állóképessége van ahhoz képest, ami a talán xx4xx-es lehetett, amivel megvettem és utána egyszer iszonyat bedugult agresszívebb stílusú, de normál használat közben (akkor nem szintetikus tesztekkel kínoztam, csak aktívan használtam).
    Ritkán mondok ilyet, de gratulálok a Samsung-nak. :R

    Már csak azt nem tudom, hogy így mivel lehetne még vizsgálgatni az AU hatását, mert a másik SSD, ami kéznél van, az pedig egy Intel 320, de annak is olyan jól bejáratott vezérlője és éveken át csiszolt firmware-e van, hogy az sem láttam még sohase térdre rogyni (anélkül pedig nem igen jön ki a bokorból a különbség -- már HA van egyáltalán 4k és 8k közt...).

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz FollowTheORI #14996 üzenetére

    Amelyik SSD-ken eddig én próbáltam, nem billent a P/E számlálón az SE. :N
    Az SE elvileg új titkosító kulcsot generál (már ha titkosít a vezérlő) és minden felhasználói adatot tároló blokkot törölhetőnek jelöl (majd természetesen, ha jól működik, akkor a szokásos módon töröl is minden blokkot, ami még nincs, ugyan úgy, mint ha TRIM-eltük volna a teljes LBA területet blkdiscard-al vagy akár csak egy format után is üresnek nyilvánul minden AU és így hozzá tartozó LBA...)
    Szóval nem szokott az SE miatt erőszakkal törölni egy már eleve üres blokkot, csak olyan blokkot töröl amit amúgy is törölne formázás és/vagy TRIM után is. Így nem okoz többlet P/E ciklust (legalább is számottevő mértékben, mert talán minimálisan több blokkot törölhet ilyenkor, de az előbb-utóbb úgyis törlődne vagy hosszabb távon ide-oda mozogna, ha mindig "be van ragadva" valahogy: pl. sohasem rakunk már particiót oda, ahova egyszer tettünk már adatot).

    (#14998) Doky586

    Erről már sokat beszéltünk.
    Attól függ, hogy mivel formázol és mit. A Windows-os format program olvas, a diskpart program format parancsa ír.
    Friss NFTS formázás után (QUICK módban is!) pedig TRIM-el a Windows minden üres (így tehát format után logikusan tágabb értelemben is minden) LBA-t (ami a filrendszeren belül felhasználói adatoknak van, nincs rajta MTF, journal, stb)

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz mrobes #15012 üzenetére

    Sima vagy EVO? Ha előbbi, akkor nem, ha utóbbi, akkor "úgy ahogy" -> ismert, ma már javítható hiba

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz mrobes #15014 üzenetére

    Erről futott a Windows, vagy más okból piszkálhatta más program mérés közben?
    "Meg volt kínozva" előtte írás teszttel? (*)
    Más programmal és más gépben is próbáltad már mérni?

    * Ha kapott például egy random write tesztet, de nem hoztál utána létre filrendszert, hogy TRIM-elje a Windows, vagy TRIM-elted kézileg a teljes LBA területet a random read teszt előtt, hanem gyorsan egymás után futtattad ezeket sorban, akkor lehet, hogy még pakolászott odabent a garbage collection algoritmus.

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Sk8erPeter #15030 üzenetére

    "janos666 emlékeim szerint azt írta..."

    Ezt nem tudom hol és milyen kontextusban elvastad tőlem (ha ilyet írtam valahol, akkor az valószínűleg valami konkrét, nem feltétlenül általános érvényű helyzetre vonatkozhatott), de egyetlen egy szál hozzászólással az övé felett személyesen is reagáltam arra, amivel kapcsolatban most te "idéztél" engem.

    Vagy nem engem idézel, hanem nekem válaszolsz és őt idézed? :DD
    (Bocs, csak nem egyértelmű így ebben a kötegelt válasz formában.)

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Sk8erPeter #15039 üzenetére

    Bárhogy rendezteted őket a fórummotorral, a 15001 az 15000 feletti érték marad. :P

    Volt szó egyszer olyanról, hogy bizonyos SandForce vezérlős SSD-k, bizonyos firmware változatokkal (de elég sok esetben) nem nyerik vissza azonnal és teljesen az eredeti teljesítményüket a teljes LBA terület TRIM-elése után sem. A quick format pedig lényegében TRIM-eli a filrendszer alá eső üres LBA-kat, így az sem feltétlenül elég, az SE viszont igen. (A nem quick, hanem "full" format-ról is beszéltünk, de az újra összegezve van 15001-nél, hogy mikor mit csinál, és hogy egyik sem jobb, esetleg rosszabb, mint az SE vagy a TRIM a quick format-on át.)

    Illetve mesélgettem már többször példaképp egy sztorit, hogy lefeküdt egyszer a 840 Pro-m, és hogy miken ment keresztül utána, mielőtt észhez tért, és hogy ez szerintem firmware bug lehetett, mert azóta (két kiadással frisebben) szándékosan sem tudtam tesztképp sem belassítani.

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Sk8erPeter #15045 üzenetére

    --- Akkor egy hatalmas OFF, amivel lassan kitiltatom magam. ---

    Mi az, hogy "no comment", de rögtön egy fejét falba verő arcocska a "comment"?
    Ha szándékosan kötekedni szeretnél, akkor legyél kész rá, hogy legalább megpróbálják visszaütni a labdád. (Ne mondd, hogy téves a kijelentésem, amit idéztél, mert egyrészről triviális euklideszi matematika, másrészről a "feletti érték" kifejezést igen gyakran használják a mérnöki szakirodalmak.)

    Kicsit nehezemre esik elhinni, hogy a fórumos átlaghoz képest az én helyesírási hibáim a legzavaróbbak a számodra, de elnézést kérek, ha ez tényleg zavar.
    Nem állítom, hogy képes vagyok abszolút helyesen írni vagy beszélni (ezért is van bekapcsolva a helyesírás-ellenőrző), viszont a legtöbb ilyen különírás az automata helyesírás-ellenőrzőm hibája (amiről tudom, hogy messze nem tökéletes, de a valódi helyesírásom átlagban még rosszabb lenne, főként a véletlen billentyű félreütésekkel együtt, úgyhogy inkább gépelek "mint az állat", aztán hagyom, hogy kijavítsa, mert úgy általában érthető lesz).

    --- Visszatérve... ----

    Igen, szerintem általános esetben bőven elég, ha minden LBA be van fogva egy (vagy több) partícióba és az(ok) a partíció(k) formázva van(nak) (gyors módban, vagy végigolvasással, de lehetőleg nem végigírással, bár a végeredménynél az sem igazán számít ilyenkor) TRIM-et támogató file-rendszerrel (nyilván TRIM-et támogató SSD-ről és OS-ről beszélve). Viszont megeshet, hogy ez valamiért mégsem elég, az SE viszont ott is segít * (olyat még nem láttam, hogy az SE sem állítaná vissza szinte azonnal az eredeti teljesítményt, vagy hogy abszolút nem is hajtaná végre egy SSD vezérlő az Secure Erase-t, de ha elég sokáig keresgélsz, talán még ilyet is találsz).

    (* Mármint "segít" annak a bizonyos felhasználónak elérni ezt a sajátos célját, akit ez érdekel, ami nyilvánvalóan nem jelenti közvetlenül azt, hogy erre valóban szükség is van. -> Csak mielőtt valaki beleköt. :P)

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Sk8erPeter #15059 üzenetére

    Ha nem húzod elő a szőrszálat, akkor nincs mit hasogatni. ;]

    Az SE néha kényelmetlen. Nem minden OS alól működik (a gyártói szoftverek pl. nem szokták tudni 8-as, csak régebbi Windows-ok alól), OS-től függetlenül is sokszor csak hotplug után lehetséges (bootláskor lefagyasztja a security mode-ot a BIOS/(U)EFI). Úgyhogy összességen átlag otthoni felhasználónak, főleg ha nincs semmi különösebb problémája vagy egyedi igénye, akkor még tudnia is kár róla, hogy van ilyen. --- Noha hasznos lehet ez akkor is, ha eladsz használtan vagy alapos fizikai roncsolás nélkül kidobsz egy SSD-t vagy HDD-t (sőt, eredetileg ilyen szituációkra való ez a funkció, a többi már csak származtatott dolog, hogy mire jöhet még jól a gyakorlatban, mint pl. ez az SSD "resetelés").

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Vakegérke #15093 üzenetére

    Az mivel jobb, mint Windows alól újrapartícionálni?
    (Nem mint ha szerintem az segítene ezen a problémán, csak sorban haladva...)
    Nem hiszem, hogy a rejtett sallangok, mint az MSR okoznák a problémát, de diskpart-al is lehet törölni az ilyeneket (majd igény szerint kinyújtani oda a maradék partíciót) és/vagy enélkül létrehozni egy új kiosztást (clean után), nem kötelező Linux-hoz nyúlni, ha nem ismeri.

    Sőt, Linux alatt nem a legjobb NTFS-re (vagy akár exFAT-ra) formázni, a FAT32 pedig a korlátai miatt lehet problémás, így a "partícionálni és formázni"-ból csak az előbbit próbálnám Linux-on (ha egyáltalán).

    Én inkább azt próbálnám ki, hogy a Linux-nak is van-e problémája a HDD elérésével reboot vagy ki/be-kapcsolás után, és ha nincs, akkor ki lehetne próbálni egy másik Windows-t (ugyan azt újratelepítve, vagy tesztképp egy másik verziót), vagy gyártói SATA driver-t, esetleg a laptop BIOS/UEFI frissítését...

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Vakegérke #15096 üzenetére

    És Windows alatt talán nem? :U

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Vakegérke #15099 üzenetére

    - Mert a GUI elrejti, de a parancssoros diskpart nem.
    - Nem vagyok szaki, csak lelkes amatőr.
    - Elhiszem, csak a Linux felesleges, ha nem szokta használni. Sokkal messzebb van letölteni, kicsomagolni pendrive-ra, bootolni róla, megismerkedni a particiókezelőjével, stb, mint előkapni a diskpart-ot, amit talán szintúgy először használ életében, de kapásból kéznél van és Windows-os logikát követ (Linux alatt akár olyat is tud csinálni, ami nem egészen lesz Windows kompatibilis).

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz ubyegon2 #15103 üzenetére

    Tudtommal a gparted igazából szétb@ssz@ az NTFS-t (mikor piszkálja az alatta lévő partíciót) és csak megjelöli a Windows-nak, hogy majd tegye rendbe, ha legközelebb találkoznak. Szóval igazából, ja, szerintem akár ezt is mondhatjuk. De nem erre gondoltam, hanem hogy pl. Windows által nem támogatott partíciótípusokat is létre tudsz hozni (GPT-nél, ha elveszel a legörgethető menüben).

    Használható, a gyakorlatban jól működik, csak nekem kicsit idegen, hogy Windows-os problémára Linux-al lövünk, mikor a Windows-nak is van erre alkalmas fegyvertára.
    Ha Linux-al van gondod, akkor sem Windows DVD-ről bootolsz, vagy igen...? ;]

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz stigma #15124 üzenetére

    Ha nem használod, akkor nem. Én az UEFI setup-ban is letiltottam.

    Ez az INF Setup általában semmit nem telepít újabb Windows-okon és friss chipsetekhez, bár némelyikben talán van AHCI driver, amit nem fontos, de nem is árt feltenni.

    Nagyon fontos dolgokat lehet találni ebben az Intel csomagban. ;] :DD :))

    ; ************************************************************
    ; ************************************************************
    ; ** Filename: Chipset_Win7only.inf **
    ; ** Abstract: Assigns the null driver to devices **
    ; ** for yellow-bang removal on Windows* 7/8. **
    ; ************************************************************
    ; ************************************************************

    -> Telepíti "a semmi" driver-t, hogy ne lógjon egy sárga ikon az eszközkezelőben.)

    Ezen kívül még régi Windows-okhoz és/vagy öregebb chipset-ekhez tartalmaz USB 2.0, SMBus, Thermal sensor driver-eket, amik frisebb Windows-ra akkor sem szokott felerőltetni, ha újabb verziók, mint a Windows saját könyvtárában található, mert ezek általában nem valódi driver-ek, csak INF file-ok, amik elnevezik a hardware-t az eszközkezelőben, de nincs melléjük DLL file, vagy bármi konfigurációs script.

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz ttrap #15146 üzenetére

    Hát a random műveletek lassabbak, mint amiket ezen az SSD-n méregetni szoktak, viszont régebbi AMD chipsetekkel nem annyira szokatlan, hogy valamelyest elmaradnak az Intel chipsetes mérésektől, és a CPU-d sem egy észvesztően gyors példány. De nehéz elképzelni, hogy ilyen gépben ezek a különbségek számottevően közvetlenül érezhetőek.

    Talán "beragadt" a gép energiatakarékos módba akkor is, ha nem úgy állítottad be. Néha megesik (a legutóbbi AMD Catalyst frissítés után beragadt nálam minimális órajelre a CPU - az érezhető volt...).

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz ttrap #15159 üzenetére

    Megnézted már, hogy nincs-e véletlenül korlátozva a maximális CPU frekvencia?
    Korábban írtam, hogy nálam volt mostanában ilyen bug a Catalys driver-el, hogy beugrott az órajel csúszka a minimumra egy frissítés után. Attól elég lomha lett a laptop (érzésre nem csak arányosan annyival, mint amennyivel az órajel volt alacsonyabb, hanem sokkal, azt hittem összeomlik a Windows).

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Süvi #15167 üzenetére

    Ha zavar az írás, akkor megpróbálhatod átrakni ezt a temp mappát egy HDD-re. Lehet, hogy a program beállításaiban is találsz hasonlót (ha nem a grafikus felületen, akkor egy ini vagy cfg file-ban vagy a registry-ben), vagy ha nem, akkor próbálkozhatsz egy NFTS junction-el.
    Da ha nem mozgatsz rendszeresen több száz Gb-nyi fotót, csak alkalmanként pár száz Mb-nyit vagy ritkán pár Gb-nyit, akkor szerintem sz@rd le olyan magasról, hogy ne is lásd hova pottyan, csak szállj szabadon, mint a madár. :D

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Sk8erPeter #15175 üzenetére

    Lehet, hogy ma már más a helyzet, de mikor utoljára használtam, akkor az volt a menetrend, hogy a filerendszert nem tudta rendesen kezelni, csak a partíció méretét szabta át és félmunkát végzett a filerendszeren, amit megjelölt "dirty"-nek, hogy a chkdsk majd tegyen rendet, mikor legközelebb csatolni próbálja a Windows. Ez pedig problémás lehet, ha a bootoláshoz és/vagy chkdsk futtatáshoz szükséges file-ok az érintett partíció(k)ra esnek (vagy valamiért mégsem fut le helyesen az az automata chkdsk, mert tudatosan vagy véletlenül félbeszakítják/letiltják, stb).

    Linux alatt eleve reverse engineering alapú az NFTS kezelése. Nincs rá garancia, hogy bármit is jól csinál, csak remélni lehet, hogy nem lesz baj, mikor nem csak olvasni próbálsz róla, hanem írni is, de főleg ha így manipulálni. Általában nincs gond, de lehet. Úgy érdemes erre tekinteni, hogy bármikor lehet gond és csak örülünk, hogy legtöbbször nincs.

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Sk8erPeter #15179 üzenetére

    A Windows is kezelhetne ext4-et és/vagy megnyithatná az NTFS-t a Microsoft, esetleg mindkettő támogathatna egy új filerendszert (amit vagy a Microsoft vagy valaki más indít el nyitottan). Egyik sem valószínű.

    Azt a kijelentést még azzal kapcsolatban tettem, mikor valaki egy Windows-os felhasználónak javasolta, hogy diskpart helyett gparted-el kezelje a csak Microsoft féle filrendszereket tartalmazó partícióit.

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Doky586 #15212 üzenetére

    Lentebb írtam, de itt van az eredeti project FAQ: [link]

    3.8 How was the Linux NTFS Driver written?

    Microsoft haven't released any documention about the internals of NTFS, so we had to reverse engineer the filesystem from scratch. The method was roughly:

    Look at the volume with a hex editor
    Perform some operation, e.g. create a file
    Use the hex editor to look for changes
    Classify and document the changes
    Repeat steps 1-4 forever

    Ez a végtelen ciklus lényegében ma is zajlik, csak míg az ismétlések száma a végtelenhez, úgy a hiba valószínűsége a nullához konvergál és már elég régóta használják az emberek, alaposan le van tesztelve.

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Doky586 #15230 üzenetére

    Ki mondta, hogy nem lehet? :U
    Az Androidos telefonomban lévő cserélhető SD kártyát extFAT-al formáztam, ráadásul magával a telefonnal (tehát nem csak olvasni, vagy írni is, de még létrehozni is képes már a Linux exFAT filerendszert). Persze nem gyári OS fut rajta, hanem Cyanogenmod + custom kernel + custom recovery. (Minden írható belső tárhely F2FS -> erre céloztam a múltkor, hogy érdekes lenne, ha esetleg elkezdené támogatni a Windows is, mint egy közös új alternatívát).

    (#15231) NetTom

    Ezt már tőlem is kérdezték sokszor, és mondtam nekik, hogy az IOMeter tökéletes a feladatra, csak épp azzal, ha túllépik a gyártó által megszabott keretet, azzal esetleg érvénytelenné válik, mintsem cserét fial a garancia (legfeljebb csak "szerencséjük" lehet, hogy közben előbújnak a gyenge cellák és a szektorhiba számláló hamarabb éri el a korlátot, vagy hogy megsül a vezérlő menet közben, stb). Szóval hülyeség... :o

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz Bodor #15241 üzenetére

    Ez mondjuk kicsit fura, ha a jelentősen drágább Pro verziót korlátozzák ilyen téren, míg a sima 840-est nem. :U

    Amúgy nem is látom most a 840-est a samsung.hu-n, pedig a 830 még kint van.
    (Más nyelven nem néztem, mert országonként eltérhetnek a garanciális feltételek.)

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz margithid #15247 üzenetére

    A 840Pro 128Gb-ra napi 40Gb van megengedve a Samsung honlap szerint, én pedig átlagban pont ennyit írok rá (naptár szerinti 24 óránként ~40-et, 24 üzemóránként kb ~80-at). Bár ebben a ~29Tb-ban benne van 2-3Tb ami igazából felesleges volt (tesztelés), és ha szerettem volna, még másik 2-3Tb-ot biztos megspórolhattam volna (pl. nem használnám átmeneti tárhelynek akkor is, ha ráérnék HDD-n belül másolgatni valamit), illetve még másik 5-6Tb-ot, ha kompromisszumosan HDD-re raknék TEMP mappákat/file-okat, viszont oly' mindegy, hisz még így pazarlóan sem éri majd el a 0% kondíciót, mielőtt naptár szerint lejár a garanciája (2 év alatt 100-ról lement 10-re, tehát marad még 8, mire leperegnek a P/E ciklusok).

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz radi8tor #15248 üzenetére

    Ebből a tanúság az, hogy ha valaki rengeteget akar írni egy SSD-re, az ne a drágább Pro-t, hanem az olcsóbb EVO-t vegye, mert ott kedvezőbben a garanciális feltételek ... nagyüzemi felhasználásra! Szupi! :K :)) :DDD

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz radi8tor #15252 üzenetére

    Ez a Media Wearout Indicator nem Intel SSD-k SMART adatai közt szokott lenni? Nálam a 840 Pro Wear Leveling Count-ot mutat (ami decimális nyers értékben elvileg Program/Erase Cycle), de ez tudtommal az EVO-kon is megvan!? :F (A SandForce-nál pedig LifeCycle, LifeCurve, vagy hasonló rémlik erre, ami nem tudom pontosan mit ad ki nyers értéknek.)

    Persze, jó látni. Gyakorlatilag viszont csak annyit nyerek vele, hogy törhetem a fejem miért ~1.5x a write amplification (WLC * capacity / host write), ha igaz, hogy WLC=PEC. Nem, mint ha nem férne bele a büdzsébe, csak érdekes. Az alaklmankénti tesztelgetés biztos felfelé húzta, de ez két év átlaga.

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz demmer123 #15276 üzenetére

    Univerzális tipp: NTFS junction

    Amúgy szubjektív véleményem szerint a második mondat első szavával megválaszoltad a kérdésed: sehogy ... nem kell, mármint nem kötelező, nem szükséges, hacsak nem vagy helyszűkében és foglal aránylag sokat ez a cache.

    De ez egyébként nem SSD topic-ba való kérdés, hanem a szoftver-ébe, vagy ha nincs dedikált fórumtémája, akkor valami szoftveres főtéma alatt általános segítségnyújtó gyűjtőkatlanba.

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

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