SSD híján HDD gyorsítása ramdiskkel

 ( mt9 | 2018. július 5., csütörtök - 9:04 )

Egy klasszikus HDD-vel felszerelt munkagépen dolgozom rengeteg apró fájlból álló projekten, az elérési sebesség érezhetően lassítja a munkát.

Arra gondoltam, hogy egy olyan ramdisk megodlás, ami valahogy garantálja az adatok tartósságát segíthetne. Próbáltam keresni ilyet Windows 10-re, olyat találtam, ami induláskor és leálláskor szinkronizál, viszont ez nem tűnik biztonságosnak, olyan kellene, ami folyamatosan teszi. (raid mirror ramdiskkel? :))

Azt hiszem megoldható a probléma manuálisan úgy, hogy induláskor feltöltöm a ramdisket, majd ráindítok egy folyamatosan futó backup alkalmazást, de gondoltam megkérdezlek titeket, hátha tudtok valami all in one megoldásról, esetleg van jobb tippetek a probléma orvoslására.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Nem ismerem a projektet, nem ismerem a büdzsét de mikor egy 64G-s SSD bruttó 8-9e nem kezdenék el ilyen megoldásokkal szórakozni. Főleg ha a projekt fájlok elvesztése jóval többe kerülne.

Mert ugye a RAMDISK az minden csak nem biztonságos.

Fedora 27, Thinkpad x220

Nettó 8-9-ért meg 120-as is van, ha már munkagép.

jaja, csak gondoltam legolcsóbbat mondom, ha arra nem telik akkor az projekt annyit is ér :>

Fedora 27, Thinkpad x220

Esetleg nem maszek az illető, hanem alkalmazott, a vezetés megszorít, ő maga meg saját pénzéből nem költ rá.

+1

Amúgy igaza van itt mindenkinek, jó volna az az SSD, még ha nem is oldaná meg a problémát, mert izmosabb proci is kéne. De most azzal tudok gazdálkodni, amim van, memóriát úgyis most bővítettek a kérésemre, nem lehetek pofátlan újoncként.

Ha meg tudod indokolni, akkor lehetsz (az nem pofatlansag, hanem szukseg). Ha a tapasztalat hianyat kell megoldania a hardvernek azzal vitaba lehet szallni a fonoksegnek.

-----
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

2018ban? De lehetsz. Es ez nem pofatlansag. Szaros 10krol beszelunk ;)

+1, óvatosan de csak meg kell pedzeni, keress egy max nettó 9990 Ft-s példányt és nyújtsd be, hogy ezzel sokat lehet gyorsítani a gépen és kellllll a munkához.

PS: inkább legyen ez a b.) terv, a.) tervnek nyújtsd be pl ennek a nettó árát (kb 12300):
https://www.pcx.hu/kingston-240gb-sa400s37-240g-ssd-meghajto-864826
ezen komoly trükközés nélkül kényelmesen elférnél és biztosan könnyebb lenne egy az egyben átmásolni a rendszert egy ilyenre.

De lehetsz. Sőt, legyél. Ha ebben visszafogod magad, azt hiszik majd rólad, hogy félsz a teljesítménykényszertől. Követeld meg, ami a munkádhoz kell és villants nekik olyat, amilyet még nem láttak soha.

úgyis most bővítettek a kérésemre, nem lehetek pofátlan újoncként

Újoncként is a napi fizetésed több, mint amiről itt beszélünk! Amúgy ha egy cég nem képes bármikor elkölteni egy termelő ember alapvető munkaeszközére az egy havi bérköltsége 10%-át, akkor ott igen komoly gondok vannak. (gyk: abból a 10%-nyi pénzből egy vadiúj sarkiboltos pc-t lehet venni).

Akkor jön a "ez így marad, mert nincs rá megoldás"
Alkalmazottként pont nem érdekelne, hogy a eszközök hibája miatt munka helyett kávézni kényszerülök - de hogy nem inoválok olyat, ami ha bebugol, én leszek a hibás, az szentség

Hát a vezetés nálunk sem költött rá, de én viszont igen. Az én időm, az én idegességem, nekem megért 25eFt-ot, hogy a céges notebookba vettem egy 250-es SSD-t. 4 évig használom... utána pedig az otthoni gépben. (5 év gar.)

Vigyázni az olcsó SSD-kkel, teszteltem párat és 70 MB/s volt az írás maximum sebessége és 120 MB az olvasásé 4-500 helyett, illetve 4K I/O 80k helyett ami kb annyi mint egy merevlemezé - és ez olyan 25 ezer FT-os SSD volt. Részemről azt javaslom hogy egyetértek, kell SSD, de minimum 60 de inkább 80 ezer IO / sec (ez a paraméter kritikus különben lassú szar lesz) és SATA3-as 600 / 600 MB rás / olvasással, wear leveling-el.

Errol azert mondj konkret adatokat is pls, melyik ssd-k voltak es hogy tesztelted.

Az egyik egy samu volt és bonnie-val (linux). Siralmas eredmények jöttek. Egyetlen parancs, futtassátok le.

és mi volt a parancs amit te futtattál? Csak mert az eredmény nagyban függ a paraméterezéstől... mennyi ram mellett futtattad, az sem mindegy.
És milyen kimenetet kaptál, mert lehet értelmezési hiba áll a panaszod mögött.

Ha egymáshoz képest vizsgálsz SSD-ket, az nem hazudik. Teszteljetek már le olcsó termékeket és meglátjátok.

De milyen parameterezessel?

Kíváncsiságból futtattam alapértelmezett módon (bonnie++ -d /hol), azaz csak a tesztfájlok útvonalát megadva, amikor a rendszer ram dupláját használja.
Hát ennek az eredménye legfeljebb csak azt mutatja, hogy nem alkalmas erősebb rendszereken mérésre, mert csak +++ -ot tesz némelyik eredmény helyére. Viszont közben némely esetben cpu limites, mert nem használja ki a többszálúságot.
Amúgy sem a háttértárat teszteli, hanem a rajta lévő fájlrendszert. Szó nincs benne iops-ról. Ha nagyon vacak értéket adott nálad, akkor lehet, hogy rosszul lett létrehozva a fájlrendszer és több blokkot ír amiatt egyszerre.

Engem pont az adott fájl rendszer érdekel az adott hardveren az adott cpu limittel. A programok sem többszálúak ha nincs leprogramozva. Ugyanazon hardveren tesztelve különböző SSD-ket nagy a különbség a sekvenciális és random elérések között (is).

Te most egyetlen SSD-re lefuttattad és ebből komoly következtetéseket vontál le? :)

Olcsó SSD-d van? Ez a gond? :) Ha igen akkor valszeg még nem próbáltál normál sebességűt ami nem HDD közeli eredményt hoz. Gondolom ezért megy itt a vita.

Á, köszi én elégedett vagyok az olcsó ssd-immel. Jól használhatóak még a régebbiek is. Még a fapados 60-as Corsair Nova2 is megfelelően megy. De a 256-os samu 470 oem változat is kitart már 6 éve. Az egyik géppel jött 180-as intel 520 és a fiatalabb 250-es msata samsung 850 evo is hibátlan.

Amúgy a samuk elég elterjedtek és jó teljesítményűek. Esetleg, ha a firmware bugos evo 840-be botlottál, azon a fw update talán segít valamennyit. Mert a lassú ssd-ről nekem a régebbi kínai, noname ssd-k jutnak eszembe, például kingdian vagy hasonlók. De állítólag már azokból is sokkal jobb teljesítményűek vannak, mint pár éve.

Csak azért kérdeztünk rá, hogy pontosan mivel, hogyan volt ilyen rossz tapasztalatod, hogy lássuk valóban van-e problémás ssd a piacon, amit érdemes kerülni, vagy csupán rossz metodikával, rosszul értelmezett méréssel van dolgunk. Minden esetre, hogy az ssd lassúságával és az io gyárihoz képest töredékével kezdted, aztán meg már fájlrendszerről meg procilimitről beszélsz, miután mondtam hogy ez történik, így látom már, hogy felesleges folytatnom ezt a szálat, mivel nincs hozzáadott érték a kapott válaszokban.

Nem értem milyen metodikára gondolsz, valami nagyon zavarhat :) Teszteltem diszkeket, nem fogom előásni az infót mert nem ér meg annyit. A teszt mindenképpen szintetikus, ezt tudjuk. Viszont sok mindent elmond ha a diszkeket egymással hasonlítod össze. Nincs itt semmiféle félreértelmezés vagy rosszul összedugott gép vagy nem is tudom még mire gondoltatok :)

Teszttől fóggetlenül, Windows-t és Linux-ot telepítve az ilyen olcsó cuccokra amivel tapasztalatom volt, nagyon lassú rendszert eredményezett. Kb mint egy SATA2 HDD, hiába új és gyors a hardver többi része. A drágább cuccnál meg penge gyors volt a boot és a reboot utáni betöltés és használat is.

Nem győzködök senkit. Elmondtam hogy érdemes odafigyelni az olcsó cuccokra mert nem igazán jók ár érték arányban a tapasztalatom szerint. Ha más máshogy tapasztalja, akkor vegyétek :)

Nem gyozkodest kertunk, csak infokat arrol hogy merted vagy milyen eszkozokon.

Engem azert erdekelt volna, mert hacsak nem a silany mar joforman nem is kaphato 32-64G ssh korszakbeli olcso ssd-rol velekedsz lassuan akkor nagyon nem ez volt a tapasztalatom (a manapsag kaphato) olcso ssdkel, ahogy hdd-nel se jott ki nalam 4000 random iops kozel se.
De mindegy, latom egyszerubb ha hagyjuk a temat.

120 GB-os Samu-t mértem 1,5 éve kb több másikkal együtt, ez volt nagyon lassú többek között, azokról nem tudok infót adni.

Milyen Samu volt ez pontosan? Nem kötekedésből kérdezem, hanem tényleg érdekel engem is.

A 32-120 GB-os SSD-k mindig is lassabbak voltak, igaz a 120 gigás már csak kicsivel, általában írásban szoktak egy 20-30%-kal gyengébbek lenni, de ezt csak benchmarkok alatt lehet kimutatni, meg nagyobb fájlok másolásánál, átlag felhasználásnál nem érzed őket lassabbnak (boot, programok betöltési ideje).

Linux alatt az a legnagyobb baj, hogy nincs normális meghajtóbenchmark. A dd még cache-elés nélkül is össze-vissza mér, a bonnie++ teljesen hülyeségeket mér és az iozone sem ér fabatkát sem. Egy reménység van, a windowsos Crystal Disk Mark-nak az MIT licences open source MS DskSpd az alapja, ami viszont van linuxra, de a felparaméterezése annak sem jól dokumentált, nekem nem sikerült vele olyan konzisztens eredményeket mérni, mint a windowsos változattal. Pedig a CDM-et sem tartom a legjobb benchmarknak, az ATTO és a HD Tune szerintem jobb Windows alatt, életszerűbb értékeket mérnek. Mégis a CDM-et használják mindenhol, benchmarklistákon, tesztoldalakon, SSD-s fórumtopikokban.

Nekem van pár SSD-m, van olcsóbb, drágább, 60 GB-ostól a 1050 GB-osig, igaz egyik sem kínai noname, vegyesen SATA2, SATA3, MLC, 3D TLC, egyiket sem találtam lassúnak, a legolcsóbbak (régi Samsung PM800, új Adata SU650) is mennek mint a villám, akkor is, ha csak USB3-on keresztül vannak hajtva, egyelőre olcsó átalakítóval, ami csak BOT USB módot tud, UASP-t nem. A stock 64 bites Win10 Prof ez utóbbiakról is 5-6 mp-en belül bootol úgy, hogy a fast boot ki van kapcsolva. Még a SATA2-est sem érezni lassabbnak, mikor OS és progik futnak róla, csak nagy fájlok másolásánál jön ki, hogy nem ~500 MB/sec-el másol rá másik SSD-ről/cache-ből, hanem csak ilyen 280 MB/sec körülivel.


No keyboard detected... Press F1 to run the SETUP

Ez berögzött téveszme. Miért ne lehetne mérni? Mérje le hogy milyen gyors a random és a seq írás és olvasás cache nélkül ugyanazon hardver és szoftver környezetben és kész. Bőven jó viszonyításnak.

Persze hogy egy mérés csak pár szempontból vizsgál a végtelen halmazban. És?

Mérni lehet, de nem valós eredményeket kapunk. Ennyi. Nem berögzöttség, nincs még rendes benchmark Linuxra. Aki mégis az elérhető legjobbat keresi Linux alatt, annak csak a dd-t tudom ajánlani cache-elés nélkül meg ezt az MS-féle SptDsk-et. A többi végképp nem ér semmit. Egy dolgot nem próbáltam még ki, ami várat magára, a Phornix Test Suite-nak van néhány vonatkozó benchmarkja, de az sem tűnik valami komolynak. Ebben zárkózhatna kicsit a linuxos kínálat a windowsoshoz.


No keyboard detected... Press F1 to run the SETUP

Mit nem lehet mérni? Meg inkább dd mint bonnie? Miért? :)

Mit értesz nem valós eredményen? Szerintem ilyenről nem lehet beszélni jelen esetben.

Nem valós eredményen azt értem, hogy közelébe nincs annak az értéknek, amit fájlokkal való műveletek alapján mérnénk, meg a windows alatt mért értékektől is gyanúsan elmarad, pedig a Linux lemez-I/O-teljesítménye nagyobb, mint a Windowsé. Sőt, még a gyártói értékeknek sincs közelében sem. A bonnie meg aztán tényleg olyan eredményeket mér, aminek köze nincs a valósághoz, az access time-okat SSD-n meg sokszor nem is tudja mérni (olyan alacsony neki), inkább kicsillagozza. Siralmasak. De ha akarod, nyithatunk itt a HUP-on egy általános linuxos SSD-s topikot, megegyezünk a benchmarkparaméterekben, mérési módszerekben, és mindenki mér syncelt dd-vel, bonnie++-szal, MS SpdDsk-kel, esetleg Windows alatt Crystal Disk Mark, AS SSD Benchmark, ATTO Benchmarkkal, mindegyikből a legújabb verzió. A benchmarkokat általában min. kétszer kell lemérni, egyszer 0-fill eredményekkel, mert néhány SSD vezérlője tömörít és csak 0-fillel lehet a gyári sebességértékeket megkapni. Esetleg lehetne még csatolni smartctl -a kimenetet is. Hasznos lenne SSD-körképnek is, melyik mit tud, mennyit megy, hány nap után mennyi üzemórán és írásmennyiségen áll.


No keyboard detected... Press F1 to run the SETUP

Túlbonyolítod.

> Mérni lehet, de nem valós eredményeket kapunk.

Huha. Fogok egy 6GiB-os fajlt es atmasolom A-bol B konyvtarba. Es megnezem mennyi ideig tartott.
Nagy tudomany na.


5868957023 byte (5.5GiB)

real 0m20,278s
user 0m0,021s
sys 0m7,504s

Nalad egy ilyen mutatvany mennyi? Azonos particion, tehat merevlemezen belul.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Nem biztos, hogy van partíció. Másrészt ez semmiről sem mond semmit. Ha van 16 GiB RAM-od, nagyon gyors lesz, mert disk cache-be megy az adat, aztán majd kiíródik valamikor, legkésőbb egy sync, umount, vagy a gép leállításának hatására. Mondjuk olvasási tesztnek azért még jó lehet.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

> Nem biztos, hogy van partíció.

Lehet hogy felreerthetoen fogalmaztam. Masolas ket konyvtar kozott.

> nagyon gyors lesz, mert disk cache-be megy az adat, aztán majd kiíródik valamikor, legkésőbb egy sync, umount,

Akar meg igazad is lehet:)

Egyebkent ilyen sync-kel:
time -p sh -c 'cp b*v ..; sync'
real 12,38
user 0,01
sys 4,46

Ha tobbszor lefuttatom, akkor olyan 12+4 korul van. De legeloszor 20+5 volt.

Viszont pendriveokat rendszeresen szoktam nagy fajlok ramasolasaval tesztelni.
A legtobb irtozatosan belassul valamennyi adat masolasa utan (talan 1GB).
A normalisabbak birjak a tempot.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

A legtobb irtozatosan belassul valamennyi adat masolasa utan

Épp azért, amit írtam. Az elején disk cache-be - tehát RAM-ba - megy az adat. Amikor a kernel nem foglal már több cache-t, akkor már csak olyan gyorsan tudja azt írni, amilyen gyorsan a másik végén ürül. Tehát valójában épp ez a lassú rész a valódi sebesség.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Gondolod, ha ilyen egyszerű lenne, akkor mindenki benchmarkokkal erőlködne? Cache-elés, fájlrendszer mind beleszól, meg ezzel a fájlmásolósdival nem tudsz tisztán olvasást, tisztán írást mérni, 4K-s teljesítményt, kötegelt feldolgozást (queue depth), késleltetést (hozzáférési időt). Hidd el, nem mi bonyolítjuk, hanem valójából ilyen bonyolult.

Egyébként ez a mappaátmásolás is egy teszt, lehet alkalmazni egy tesztként a sok közül, de el kell fogadni a korlátait. Eleve a reprodukálhatósága is nehéz, mert amit a te mappáddal mértél a te SSD-den, azt az időeredményt nem tudod összevetni Gipsz Jakab meghajtóján átmásolt mappával, még akkor sem, ha a mappa mérete is azonos, mert nem fogod tudni mi volt az ő mappájában (mekkora fájlok, hány darab, tömöríthetők-e), milyen fájlrendszert használt, cache ki volt-e kapcsolva, stb..


No keyboard detected... Press F1 to run the SETUP

Lásd még: sparse file-ok.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ez a hozzaszolas egy eros vicc, ugye?:)
https://github.com/axboe/fio

Na jó, csak egy gyenge vicc volt. Próbáltam a fio-t is, egy kalap fekáliát nem ér, valahogy nem nevettem. De ha írod milyen paraméterezéssel próbáljam, kipróbálom újra.

Nagy linux meg opensource fan vagyok, meg elég MS/Windows-ellenes, de azt tisztán kell látni, hogy vannak területek, aminél a Linux le van még maradva, és ez a disk benchmarkolás még egy ilyen terület. Pedig szó sincs róla, hogy Linux alá nem lehetne írni ilyeneket, csak valahogy a fejlesztők nem motiváltak, hogy ilyesmit fejlesszenek. Pedig igény lenne rá.


No keyboard detected... Press F1 to run the SETUP

> Próbáltam keresni ilyet Windows 10-re, olyat találtam, ami induláskor és leálláskor szinkronizál, viszont ez nem tűnik biztonságosnak, olyan kellene, ami folyamatosan teszi.

Ha a RAM disk folyamatosan szinkronizál a lemezre, akkor az írás ugyanolyan lassú lesz, mintha közvetlenül a HDD-n csinálnál mindent, nem?

Sz*rk: Esetleg célszerűbb volna RSynccel manuálisan szinkronizálni, amikor úgy gondolod, hogy kell. Egy windózos RSync leírás itt.

Az írás lehet, de nem is azzal van probléma, hanem az olvasással főként (build, indexelés)

A build az rengeteg írással is jár, hiszen a generált objecteket is ki kell írnia valahova. Persze lehetne csinálni egy második RAM disket, ami nem szinkronizál és olyan Makefile-t generálni, ami az objecteket a másik RAM diskre teszi, de ez már tényleg felesleges túlbonyolítás. Én még mindig a manuális szinkronizálást választanám. Bár leginkább - ha ennyire spúr a főnökség - vennék saját zsebre egy olcsó SSD-t és beraknám a gépbe.

Aztán mikor eljön onnan megunva a fillérb*szást, lehet igazolni h. az övé az eszköz amit a céges gépbe saját pénzen vett, meg megsemmisíteni a rajta tárolt szenzitív adatokat stb. stb. stb. Saját pénzen venni a munkavállalónak munkaeszközt... aztán ha már jó sokan csinálják, ez lesz a norma és nem a kivétel. Fizetni ne fizessen még azért is, mert irodába jár dolgozni, és használja az áramot / vizet / WC papírt?
--

"Nem kéne ezektől belépőt is szedni?" :D

Eddig nem ismertem, de valóban jó vicc :)
--

Egy szóval nem mondtam, hogy a munkaadónak vegye meg az eszközt. Saját magának vegye meg és használja. Igazolásnak ott van a számla, adatmegsemmisítésre meg a dd. Szerinted mégis mit kéne csinálnia, ha az nem opció, hogy a cég vesz egy SSD-t? Szopnia a RAM diskkel, meg a szinkronizálással?

Otthagyni a helyet. Ahol nincs 10 ezer Ft egy rohadt 120 gigás SSD-re, ott nem lesz pénz rendes fizetésre sem.
--

Nem mindenki teheti meg, hogy csak úgy otthagyja a melót. A nem rendes fizetés is több a semminél.

Nem is szeretném otthagyni, nagyon jó hely, és a fizetésem elég figyelemreméltó :)

> nagyon jó hely
> sajnálnak tízezer forintot egy munkaeszközre

pick one

Sehol nem írtam, hogy sajnálják a pénzt egy 10e forintos munkaeszközre. Annyira sajnálják a pénzt, hogy pont most kértem, és kaptam memóriát. És amit írtam az az, hogy emiatt pont nem akarnék pofátlan lenni, és túlzásba esni, mert tudnék. Jézusom... Azért basszus, ami ezen a fórumon megy néha, az több mint nevetséges.

Tehát kértél, és kaptál memóriát ramdiszknek :-D

Venni köll a gép mellé egy vaskos UPS-t, a gépből kiszerelni a kikapcs gombot, és voilá, meg is van az SSD-s masina!
Majdnem.

Lehet csak szimplán túlgondolod. Kérdezd meg, hogy lehet-e. Legfeljebb nemet mondanak. Szóval lehet te vagy a hibás és nem a munkahelyed. :D

Amúgy volt ilyen nálunk is a régi helyen. Általában a beszerzések nagyon lassan és bizonytalan kimenettel történtek. Viszont egyszer volt felmérés, hogy mindenki írja fel a listára, mire lenne szüksége. Na most az egyik projekt emberei mind felírták, hogy a 2x 19 colos hd monitorok helyett jó lenne valamivel nagyobb fullhd, legalább az egyik helyett, mivel a modern fejlesztőeszközök felülete elfoglaja már a képernyő kétharmadát a kicsiken és alig látni a kódból valamit, ami nehezíti a munkát. Páran a másik projektesek közül is csatlakoztunk ehhez.

Eltelt pár hét, majd megjöttek a monitorok. A projekt csapatomból többen panaszkodtak, hogy ők nem kaptak, bezzeg a másik projektesek igen. Amikor ezt hallotta a főnök, akkor egy érdekes beszélgetés zajlott le:
- hát, mi nem kaptunk monitorokat
- felíratkoztatok a listára?
- nem
- hát, így nem meglepő, hogy nem kaptatok
- azt gondoltuk, hogy úgysem lesz a beszerzésből semmi
- ij

Szóval, légy bátor, a helyi terminátor. Aki nem szól, annak annya sem látja a fától az erdőt :D

"Szóval lehet te vagy a hibás és nem a munkahelyed."

Ha hiba az, hogy nem akarok követelőző lenni, akkor én hát :) Senki nem mondta hogy a munkahelyem hibás, sem azt, hogy szar, sem azt, hogy kérésre nem adnának. Csak megint elkezdett mindenki kombinálni :) Magyar módi.

"Csak megint elkezdett mindenki kombinálni"

Ezen a tájákon azért nem olyan ritka, hogy valaki leírja a problémáját, aztán kiderül, hogy azért fáj neki mindenhol, bármelyik testrészéhez is nyúl, mert a keze van eltörve.

+1

kb. mindenki leírta, h. ne RAMDISZK-el baszkódjon, hanem vetessen 10 ezerért egy SSD-t (ha commercial ramdiszk sw-t kezd el használni, azért is ki kell majd ennyit fizetni hacsak nem lopja warezből, szóval pénzbe fog kerülni így is-úgy is). De ha akar tovább kombinálni, tegye nyugodtan. Az ember pár év-évtized után megtanulja elengedni azokat az embereket, akik tanácsot kértek, tanácsot kaptak, aztán csak azért sem fogadják meg a tanácsot. Ennyike.
--

Nem én mondtam, hogy hagyd ott. Ha annyira figyelemre méltó a fizu, akkor meg pláne megéri egy saját használatú SSD-be beruházni. :)

Én egy nagy multinál dolgozom. És az a policy, hogy 4 évente kapsz új gépet. Négy évente le kell adni. Mégis mi gátolna meg benne, hogy vegyek egy SSD-t magamnak a céges gépbe? Amikor meg leadom, akkor belerakom a szuper hdd-t és kész. Magamnak veszem, én használom, az én időmön spórol Nem tudom, hogy honnan vetted azt, hogy ahol hardware policy létezik az egy rossz hely, mert nem fizetnek rendesen....

Farewell To The CretinsNem tudom, hogy honnan vetted azt, hogy ahol hardware policy létezik az egy rossz hely, mert nem fizetnek rendesen....

Én is láttam ilyen céget belülről. Fizetett az rendesen, ugyanakkor a havi bérköltségem 6-7%-át sem óhajtotta a cég default elkölteni arra, hogy hatékonyan tudjak dolgozni (nyilván ebben a pozícióban nem volt nehéz jóváhagyást kapni egy ssd-re, de a tény, hogy nem azzal jött a gép defaultból). Személy szerint ezt egy orbitális nagy fasságnak tartom. Jellemző, hogy a cég azért fejlődőképes volt: mire odajutottunk a felvételemet követően, hogy na akkor mobil, addigra az a policy, hogy van három elavult modell, abból választhatsz, lecserélődött arra a policy-ra, hogy vegyél akármilyet magadnak, és $350-ig elszámolhatod a számlát (ebből simán kijött egy Nexus 5x).

Simán tilthatja a saját kütyük használatát egy komoly cégpolicy. Gondoljunk csak pl. a vírusok bejuttatására, akár SSD-n, akár pendrive-on.

Amúgy a lassúság -vagy éppen gyorsaság- sok esetben egyénfüggő is, ki mennyire türelmetlen.

--
robyboy

Ezt az idejétmúlt hülyeséget kb. 7 éve találta ki vmi idióta marketinges a spúr munkáltatók legnagyobb örömére, h. ne kelljen a melósnak céges pénzen smartphone-t venni, mégis tudja olvasni a céges leveleit bárhol.
Ha a munkáltató azt akarja h. munkaidőn kívül is elérhető legyen az alkalmazott, lesszíves neki biztosítani a munkaeszközt.
--

Háttööö... a céges ájfónt megkapta használatra a lányom (telefonnak tök fasza, okostelefonnak nagyon komoly, mert viccnek rossz volna), én meg a saját kínaimról hívom a főnököt és viszont a céges kártyával. Nem mondhatom, hogy nem kaptam használatra eszközt.

Háttööö a bring your OWN device-ban az "O" azt jelenti, h. a cég nem ad neked céges iphone-t, hanem a Te saját telefonodba kapsz céges SIM-et, és használod tovább a saját telefonodat munka ügyben (is). Papíron a melós boldog mert a saját szája íze szerinti eszközt használ tovább, nem pedig azt a típust amit a cég előír. Ugyanakkor ha tönkremegy / elavul, veheti a saját zsebéből az újat. Holott munkaügyben (is) használja az élettartama alatt, azaz termelő munkát (is) végez rajta.
--

Nem.
Azt jelenti, hogy a sajátodat IS használHATod.

Hogy ezt a "munkakör betöltésének feltétele saját személygépkocsi" alapokon 30 éve itt úgy magyarítjuk, hogy "hoznod KELL a saját eszközödet", arról nem a gyíkvoltában eszét vesztett háttérhatalom tehet.

Maradjunk annyiban, h. lehet így is úgy is értelmezni, pont mint a törvényeket. Az a munkáltató, aki fillérb@szó, úgy fogja értelmezni ahogy neki kedvező. Azaz h. nem kell még egy céges telefont is adni a dolgozónak, ha már úgyis mindenkinek van sajátja. Milyen jófej munkaadó vagyok, használhatod a kedvenc telefonodat a céges dolgaidra is!
--

Igen, jófej, ui. nem kell ahhoz Klintonnénak lenni, hogy valaki üzleti/ipari titkokról beszéljen a telefonján, vagy annak a kamerájával ilyen titkok közelében sétáljon gyanútlanul.

A BYOD-nak mi köze van ahhoz h. a melós mmilyen ipari titkokhoz fér hozzá?
--

Ahhoz semmi, hogy a melós mihez férhet hozzá; szemben azzal hogy az általa használt eszközön keresztül ki mihet férhet hozzá.

Na meg olyannal szoktam találkozni, hogy "adunk neked céges laptopot meg telefont, amit haza is vihetsz", persze hogy 24x7-ben elérhessenek, ha ég a ház.

Érdekes értelmezés.

Ahol eddig ilyesmivel találkoztam, nem ezt jelentette.

A cég adott céges telefont, céges sim kártyával, és bekonfigurálva, hogy ügyesen magától csatlakozzék a céges wifi hálózatra.

És ha a BYOD requestet kitöltöttem, akkor adtak egy usernév jelszó párost, ami ment mondjuk egy hétig, vagy egy hónapig, és azzal a saját magán telefonom is fel tudott csatlakozni egy guest wifire, amiről nem érte el a céges erőforrásokat, cserébe a mobil adatkeret fogyasztása nélkül tudtam appokat frissíteni, szinkronizálni, magán emailt olvasni, stb.

Másik cégnél (számunkra ügyfél), nekünk, külsősöknek, a céges (számukra beszállítói) laptopokat pl. nem engedték be a saját belső hálózatukba, hanem a BYOD regisztráció után a guest wifin át tudtuk elérni az internetet, a levelezést meg mindent.
Azt nem tudom, hogy ott az alkalmazottak kaptak-e telefont, vagy csak sim kártyát, vagy hogyan volt ez.

Ahol meg én találkoztam ilyesmivel, ott azt jelentette, hogy tetszőleges eszközt (Windows, OSX, iOS, Android) beregisztráltál a device management rendszerbe, és onnantól minden céges erőforrást elértél vele. A BYOD ezt jelenti, a többi csak maszatolás.

Kaptam ugyan céges eszközöket is, nagyon örült neki a család. :)

Az, hogy egy internet-only wifit el lehet vele érni, az kurvára nem BYOD. Azt tudja kb. bármilyek cég manapság.

Jah, a dolog kb. VPN-nél kezdödik, és Exchange szinkronizációval, Intranet-eléréssel végzödik.

--
robyboy

Nagyon sok olyan cég van, ahol nem megy ez még.

Sőt, ennél viccesebb, hogy az elmúlt két héten a saját cégem külföldi irodájában voltam, és a saját belső wifinket is csak erős korlátozásokkal tudtam elérni (telefon nem kapcsolódott rá, a laptop igen, de csak az intranetet látta, és pl. a levelezést sem).
Így végül 4G-s wifi dongle segítségével dolgoztam.

"A build az rengeteg írással is jár, hiszen a generált objecteket is ki kell írnia valahova"

Nem voltam specifikus a feladatot tekintve. Angular projektről van szó. Ahol kritikus a build time, az a fejlesztés közben futó folyamatos build, ami során a memóriába kerül a végtermék, és onnan szolgálja ki a dev szerver. Nincs írás, legjobb tudomásom szerint még temp fájlok sem.

ProcessMon-nal kiderítheted, hogy firkál-e a transpiling alatt a diskre, vagy sem.

linux alatt lehet olyat haxolni, hogy mdadm egyik laba egy ramdisk device (dev/ram0) masik rendes hdd. megadhato hogy olvasasra csak a ramos labat hasznalja, igy az gyors lesz. az irast meg igyisugyis megkell csinalnia a hdd-nek.

De amugy jah, vegyel egy olcsobb ssd-t, ha felszorzod a orabered meg az elb.szott idot a haxolasra (ha meg bubanc van akkor az adat helyreallitasra forditott) es mar nem is olyan draga az ssd...

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Ilyenkor minden boot-nál RAID hiba és újraszinkronizálás?

Linux alatt valsz eleve nem kell ezzel küzdeni. A fájlrendszer kezelése és bufferelése sokkal jobban működik ott.
Régebben csináltam tesztet, hogy konzólból indítva egy android projekt buildjét hogyan alakul az idő win és linux alatt. Win alá 2x erősebb hardver kell hasonló sebességhez. Linux alatt az sem sokat számított, hogy ssd vagy hdd volt alatta, hdd esetén csak az első alkalommal volt valamivel lassabb, utána már bufferelt volt és simán ment.

T61, c2d t8300, Ubuntu 16.04 LTS : 4m 03s
desktop i5 760, Win7: 3m 56s
T430, i5-3320m, Win10: 3m 58s
T430, i5-3320m, Ubuntu 16.04 LTS: 2m 32s
T430, i7-3720qm, Win10: 2m 42s
T430, i7-3720qm, Ubuntu 16.04 LTS: 1m 56s

De anno volt más projekt is, ahogy nagyságrendekkel több volt win-en az idő, s ahogy néztük mi eszi a procit, úgy láttuk, hogy a fájlrendszer kezelése vitte el 90%-át a build közben (ms vc fordítóval volt qtwebkit).

> mdadm egyik laba egy ramdisk device (dev/ram0) masik rendes hdd.

Vagy overlayfs. Olvasas vinyorol, iras meg ramba megy.

Vagy tmpfs es systemd service, ami felmasolja a szukseges fajlokat a tmpfs-re bootkor.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

^ híres utolsó mondatok című műsorunkat látták :D

ezt mire írtad?

A házi barkács cache-ben dolgozás, aztán perzisztálás nem életbiztosítás.
Bár emberi léptékű gépelés és kiírásfrekvencia mellett a para túlzott.

Tipikus usecase: Kódolok. Pár kilobájt íródik percenként 1-2 alkalommal. Miről beszélünk? Értelmes szinkronizálás maximum pár századmásodperccel később rögzíti a hdd-re a változtatást.

Barkács? Nem tákolmányt használnék, hanem célszoftvert. Adtak fent jópár hasznos tippet a többiek. Még tesztelni nem volt időm, de feltételezem, hogy akad köztük kiforrott, jól tesztelt szoftver.

Néhány kilobyte HDD-re írásának idejét szerintem nem veszed észre.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem hát. Nem is mondtam, hogy az írási sebességgel van problémám :)

Olvasásra lassú? SSD lenne az optimum. RAM diskkel az a bajom, hogy ha gyakran szinkronizál, nem sokra mész vele, ha meg csak a gép leállásakor, akkor pedig egy esetleges megdöglés alkalmával nagyon cudarul fogod magad érezni, mert oda egy napi munkád.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szerintem félreérted.

Nyilván a ramdisk önmagában veszélyes, ezért kerestem olyan megoldást, ami szinkronizál HDDre. A ramdiskre írás így iszonyú gyors, az olvasás iszonyú gyors, az adatok tartós tárolása pedig kis késlekedéssel (századmásodpercek, tekintve hogy alig van írási művelet) megoldódik, tehát adat nem nagyon tud elveszni.

Szinkronizálás alatt olyasmit értek, mint mondjuk amit a dropbox csinál. Nem ismerem az ide vonatkozó terminológiát.

BTRFS fájlrendszer tömörítéssel (compress=zlib paraméterrel) elég jól növeli a sebességet. Még a kukázott 40 gigás Maxtor diszken is teljesen jó sebességet produkál, mert a tömörítés miatt kevesebb adatot kell olvasnia a diszknek. Cserébe az írási műveletek lassabbak lehetnek.

-------------------
https://onlinestream.hu/ - A legtöbb magyar rádió és TV egy helyen!

Ramdisk Enterprise. Messze a legjobb ramdrive, sokéve használom kliensen, szerveren.

Tud image file-ba szinkronizálni, olyan gyakran amilyen gyakran szeretnéd. (és még ezer mást is)

ReadyBoost usb stick-kel nem jatszik?

--
robyboy

SuperCache és hasonló szoftverek tudják. Általában bármelyik komolyabb RAM disk proginak van ilyen funkciója.

Vagy feltesztek Linuxot, ott a kernel alapból izomból cache-el mint az állat, ha van elég szabad fizikai memória, nem kell hozzá semmilyen hack meg spéci szoftver. Ráadásul a profibb cache-elést leszámítva is a linuxos fájlrendszerek alapból gyorsabbak is, mint az NTFS, kevésbé töredeznek, főleg apró fájloknál rettenet látványos a különbség, a hajad leteszed tőle, ha előtte csak Windowst használtál. SSD-nél ez nem annyira jön ki, inkább lassabb HDD-knél látványos nagyon. Tudom, írták már előttem, de ezt én is megerősíthetem.

Az SSD-t is mindenképp fontoljátok meg, ma már kötelező minden gépbe, főleg Win10 alá, ami mániákusan tekeri a lemezt. Egyszerűen SSD nélkül felejtős a wintizezés. 9-10 ezerért vannak újonnan használható 120 gigás SATA3 SSD-k 3 év garival, azok között is jelenleg az Adata SU650 az egyik legjobb vétel. Ha cégként veszitek nagy tételben, áfavisszaigénylős/leírós mókában, akkor végképp filléres tétel.


No keyboard detected... Press F1 to run the SETUP

sub
--

HDD-vel nem lehet egyszerre gyorsan és biztosan. Vagy a biztonságot gyengíted, vagy a sebességből adsz alább. Akármilyen csodaszoftver akármit is állít, nem lehet mindkettőt.

Mellesleg a windóz eleve RAM-ot használ HDD gyorsítására. Az alkalmazások által le nem foglalt fizikai RAM-ot lemez cache-nek fogja használni. Azonban hiába próbálkozol bármivel, pl boot után ugyanúgy lassú lesz első alkalommal felolvasni a fájlokat, mert a HDD a szűk keresztmetszet. Írásnál eleve a cache-be ír, legjobb tudomásom szerint write-back módban üzemel, azaz alkalmazás szempontjából az írás a cache-ben fejeződik be, és a háttérben üríti a lemezre, néhány mp-en belül.

Ramdiszket akkor érdemes használni, ha a fájlok nagyon rövid életűek és el lesznek dobva a francba nagyon hamar, nem kell őket külső hordozóra menteni. Ha kell a sok kicsi fájl, akkor nem sokra mész a ramdiszkkel a normál beépített cache-eléshez képest, illetve ha eleve csak 1x olvasod be a sok kicsi fájlt, akkor is felesleges az egész.

A ramdiszk esetleg még akkor lehet jobb, ha kevés a RAM-od, és az alkalmazások amúgy elvennék a lemez-cache elől. Persze ilyenkor meg előbb-utóbb swappelni fog a win, ami megint csak lelassít mindent.

Vegyél SSD-t, a legolcsóbb, legszarabb cucc is köröket ver HDD-re.

Persze, hogy cache-el a Windows is alapból, csak nem valami jól, ezért is építenek be külön cache-t a ramdiskes szoftverekbe. Ebben még lenne bőven hová fejlődnie a Linuxhoz képest.

Nem véletlen adnak SSD-khez is gyári windowsos szoftvert, ami külön tud „csodacache-elést”. Samsungnál a Samsung Magiciannek a Turbo Cache nevű megoldása, Crucialnál a Storage Executive Toolnak a Momentum Cache nevezetű megoldása.

Persze minden OS cache-el már régóta, a kérdés a hatékonyság. Már DOS alatt is lehetséges volt a smartdrv használatával.

Én inkább ott látom a szoftveres megoldások buktatóját, hogy a külön RAM cache akkor segít, ha van bőven elég fizikai memória, de ha arra volt pénz, akkor egy SSD-re is lenne. Ha valaki nem vesz 120-250 GB-nál nagyobb méretet, akkor az NVMe-s SSD-k sem drágák már, bár olyat is csak annak érdemes venni, aki ki is tudja hajtani, átlag felhasználói szoftverek nem szokták tudni kihasználi, azoknál bottlenck van már SATA2, SATA3 környékétől.


No keyboard detected... Press F1 to run the SETUP

hmmm... ez a "csodacache" dolog kissé hogy is mondjam... hókuszpókusz szagú. Nem tudom, mit csinál például a Samsung Turbo Cache cucca, de én jó szoftvert a koreaiaktól még nem láttam. Ez szerintem ilyen CCleaner dolog lehet, csinál valamit, amiről el tudják hitetni pár emberrel, hogy tényleg használ. Talán még van is olyan use-case, ahol tényleg segít egy picit. Ártani viszont tudnak, ha nem jól vannak megírva.
A Crucial-nak a Momentum Cache-e meg SSD-kre van, de szerintem a csoda samu szoftver is.

Windózon az NTFS lassú és töredezik. Az egyik legjobb fájlrendszer feature-öket nézve, nagyon megbízható és borzasztó rugalmas, csak lassú. Ráadásul a windóznak egyéb bajai is vannak, ha HDD-t kell kezelni, ami nem segít a lassú NTFS-en. Cserébe FAT32 vagy exFAT gyorsabbak (ha nem kell ACL meg egyéb nyalánkságok)
Továbbá érdekes lehet a btrfs driver windózra, egyes tesztek szerint a random kicsi read-write-ok gyorsabbak vele, mint NTFS-el, viszont biztosan nem annyira stabil.
Esetleg ext3, arra is van Win driver, és eléggé gyors is, régebben sokat használtam.

A Samsung Turbo Cache-e is SSD-re van. Csak a saját SSD-jükkel megy. Az, hogy gyorsít-e a lemezműveleteken, az attól függ, hogy mire használod. A nagy fájlokkal történő munkát gyorsítja, de átlag felhasználók nem nagyon használnak ilyeneket. A sok kicsi fájlt érintő lemezműveleteket valószínű nem nagyon. Csak azért említettem, hogy ha ki akar próbálni valaki a Windowsénál fejlettebb cache-elést, de nem akar Linuxot feltenni.

Így van, az NTFS lassú. A legszomorúbb, hogy a MS nem fejleszt modernebb fájlrendszert, hiába a ReFS, az sem gyorsabb semmivel, csak feature-öket adtak hozzá. Linuxos fájlrendszert pedig nem hajlandók rendesen támogatni. Ennek szerintem az az oka, hogy beköszöntött az SSD-korszak, és a gyors SSD-k elfedik az NTFS borzalmas lassúságát, így haladékot kapott.

Ezek a nem hivatalos linuxos fájlrendszerdriverek meg olyanok Windows alatt, hogy mennek, meg az adataidat eléred velük, de a teljesítményük nem valami jó. Én ext4-gyel próbálkoztam, igaz LUKS-oson, de hát nem futott valami hűdejó teljesítménnyel. A FAT32, exFAT meg vicc így már 2018-ban. Maximum pendrive-ra valók, nem rendszermeghajtóra.


No keyboard detected... Press F1 to run the SETUP

A nagy várományos ReFS -ahogy írja a szakmai közösség internetszerte- nem hogy nem gyorsabb mint az NTFS, hanem egyenesen lassabb, ill. néhány workload-nál sokkal lassabb! Ami annak fényében különösen szomorú, h. az NTFS szinte összes okosságát (ACL, quota) pont hogy kiszedték belőle! Win10-ből is mostanában kivették a Refs support-ot (kivéve céges release-k).

http://www.joshodgers.com/2016/07/10/storage-performance-refs-vs-ntfs/
https://arstechnica.com/gadgets/2017/08/microsoft-to-remove-full-refs-support-from-windows-10-pro-push-workstation-sku/
--

Dolgozz pendriveról! Rögtön szélsebesnek fogod a hdd-t érezni. :D

--
openSUSE 42.2 x86_64

Közel sem biztos, nekem van olyan pendrive-om, amin egy Windows 10 virtuális gép van, tökéletesen lehet vele dolgozni. Nyilván nem olyan gyors, mint egy SSD.

Pendrive és pendrive között van még csak igazán óriási sebességjülönbség! Ha eddig csak ócskaszar repi-ajándék USB 2.0-s pendrive-okkal vert meg a sors, nézd meg mire képes egy USB 3.0, neadjisten USB 3.1-es pendrive egy megfelelő USB-t beszélni képes gépen! Kb. mint a HDD-->SSD váltás.
--

USB 3.x pendrive-ok között is nagy különbségek vannak, sebességben és árban, még akkor is, ha azonos tárterületűek.


No keyboard detected... Press F1 to run the SETUP

Ezért írtam h. a rendezvényeken hozzámvágott ismeretlen gyártós ingyenpendrive és egy márkás 3.x-es között óriási a különbség.
--

A nagymárkás is lehet hulladék, csak más rajta a matrica, mint az ingyenpedriveon.

Sandiskeket használok, adathurcibálásra tökéletes. Amúgy külső SSD-t, vagy Seagate HDD-t, ha valami nagy kell gyorsan.

--
openSUSE 42.2 x86_64

Azért ezt nem lehet ilyen sarkítva megfogalmazni. Még márkás pendrive-ok között is van különbség, pl. a USB3.0-ás Corsair Flash Voyager és a szintén USB3.0-ás Corsair Flash Voyager GT/GTX, egész más dimenzió a kettő sebességben, árban, pedig egyik sem dzsunka, mindkettő márkás modell, USB3.0-as vezérlővel. Nyilván a promós pendrive-ok átlalában csak USB2.0-ásak, azokból is a legalja.

Ha valakinek gyors pendrive kell, akkor érdemes inkább SSD-t venni helyette, még a belső SSD-ket is lehet egy filléres USB-SATA átalakítóval külső meghajtóként használni USB3.0-án, 3.1-en, köröket fog verni a létező leggyorsabb pendrive-ra, és árban is olcsóbbra kijön, mint egy drágább fajta fajta pendrive. Cserébe nem csak gyorsabb lesz, de jóval több írást is bír ki, és tárterületben is nagyobb.


No keyboard detected... Press F1 to run the SETUP

Az USB átviteli tempója (480 Mbps vagy több) egy dolog, ez elég lenne a legtöbb esetben.
A kérdés inkább az hogy a pendrive flash tempója milyen (olvasásra, írásra). Ebben vannak nagyon gyengék és normálisabbak.
Egy kis segítség a választáshoz: http://usb.userbenchmark.com/

Az USB 2.0 (kb 18 éves szabvány) busznak az elméleti maximuma az a 480 megabit. Azaz laborban, ideális körülmények között láttak már olyat, aki hallott már olyanról h. ment annyival. Okosok szerint a valóságban kb. a felét lehet belőle kipréselni, ami 240 mbit -> 30 megabájt/mp. Na ezért nem nagyon lehet ennél gyorsabban másolni usb2-s eszközre, még ha maga az eszköz bírná is, a csatoló lekorlátozza.
--

Erről beszélek. Ha 30 megabyte/másodpercet tudna az USB2-es pendrive, örülhetnénk. Valójában elég sok mindössze ötödét-tizedét tudja annak, amit az USB2 interfésze lehetővé tenne, mivel a mögöttes flash kezelése lassú.
Nekem is van egy ilyen 32 GB-osom sajnos. Nézd meg a specifikációját: https://www.kingston.com/datasheets/DTIG2_us.pdf
Általában nem az USB2 interfész tempója a valódi korlát, hanem a pendrive-ban levő flash írás-olvasás képessége.

Sajnos az USB3 interfésszel rendelkező pendrive-ok közül szintén van sok, amiben a flash nem hozza azt a tempót, ami indokolná az USB2-nél gyorsabb interfészt.

Ezen felül az sem elhanyagolható szempont, hogy bizony az usb kezelés CPU-t terhel elég rendesen, ami természetesen az USB átviteli sebesség függvényében arányosan növekszik.

USB3-as csatolón 100 MB/s közeli írás/olvasás már bizony eléggé lefogja az egész gépet...

--
robyboy

Én ajánlom a PrimoCache-et -- https://www.romexsoftware.com/en-us/primo-cache/purchase.html

Ez elsősorban SDD cache-ként való használatára jó, de több szinten cachel, RAM-ot is használ. Emlékeim szerint van benne olyan lehetőség, hogy induláskor betölti a korábbi cache-t. Szóval szerintem neked jó lenne. És tényleg jó egyébként, én szeretem.

A baj vele, hogy 30 USD, több gépre már jobban megéri. Szerintem én annak idején, mikor megszűnt beta lenni olcsóbban vettem meg.

Szerintem a Windows is használ disk cache-t, ami meg RAM.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Hajjajj, de még mennyire!

--
robyboy

Ezzel viszont számomra megkérdőjeleződik a RAM-disk használatának értelme. Amúgy én is így gondoltam, meglepne, ha egy korszerű oprendszer nem próbálná a burst-ös nagy sebességigényt elkenni jóval kisebb átlagsebességre közbenső buffereléssel.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Manapság a memóriaméret gyakorlatilag indokolatlanul sok, és a különböző rendszerek megpróbálják így-úgy valamire felhasználni, ha már értelmesen nem lehet. Egy biztos, egy lassú diszken nem segít semmi sem, csak egy gyorsabb diszk.

--
robyboy

Jó a hibrid megoldás is. A desktop gépemben van egy SSD, ezen van az operációs rendszer, s van egy HDD, ezen pedig az adatok, picit közelebbről a /home és a /var. Gondolom, Windows-on is meg lehet ezt csinálni.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Windows-on kb. a profil-t lehet átrakni, de az elég is, ha valaki ezt szeretné. Talán csak az az egy hátránya van, hogy nő a rendszer sérülékenysége hardverhiba esetén. Minél több HW, annál több hibalehetőség. De ennek gyakorlatilag nincs jelentősége, ha van mentés.

--
robyboy

Persze, hogy van. Néhány napja sírtam el itt a bánatomat, hogy a notebook-omban meghalt az olcsó SSD. Az újra felhúztam egy Fedora 28-at, aztán mentésből visszatettem a /home-ot, a /etc-hez puskáztam backup-ból ezt-azt, s minden úgy ment tovább, hogy lényegében semmi sem változott.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Jahh, ha egy helyett két tűzoltókészüléked van, kevésbé valószínű, hogy sikeresen oltasz el egy tüzet.

:)

Vagy a rendszered száll el, vagy az adataid, vagy mindkettő.

1 lemez = x% hibalehetőség
2 lemez = 2-szer x% hibalehetőség.

A hasonlatod ebben az aspektusban nem állja meg a helyét.

Ha egy Enterprise storage-om van, több, mint száz lemezzel, akkor minden héten fogok kb. diszket cserélni, ahogy szép sorban tönkremennek - persze ott nincs adatvesztés.

--
robyboy

A hasonlatom valóban rossz, mivel a fontos adatok elvesztésének pont ugyanakkora esélye van. Kivéve, ha a meghibásodás inkább függ a fejmozgások/írások/olvasások mennyiségétől, mint az üzemidőtől és/vagy a be/kikapcsolások számától.

:)

Rég volt már az a valszám vizsga, ugye? :P

1 lemez mondjuk 0.2 % hibalehetőség.

600 lemez akkor 120 % hibalehetőség? :DD

Ugyan nem vagyok benne biztos, de érzésből szerintem P=1-(1-x)n,
ahol x egy eszköz meghibásodásának valószínűsége, n az eszközök száma. Persze igaz, hogy kevés eszközre és kis meghibásodási arányra közelítően n*x lesz az eredmény - kicsit kevesebb -, tehát épp, amit mondtál.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

600 lemez 120% így van, egy lemez tutira tönkre fog menni a 600 közül.
Ennek pont semmi köze nincs ahhoz hogy ebből lesz-e adatvesztés vagy sem.

--
Gábriel Ákos

Persze, lehet RAID, meg minden, meg értem én a gyakorlatias megközelítést, hogy ha valamiből sok van, nagyobb az esély, hogy valamelyik megdöglik, de egy pillanatra csináljunk úgy, mint valamiféle műszaki végzettségű emberek egy hellyel-közzel szakmai portálon. ;)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ha elolvasod a szálindító hozzászólásomat, szembesülhetsz azzal, hogy egy szakmai fórumon szakmai hozzászólást olvashatsz.
Személy szerint hetente-kéthetente cserélek HDD-ket Storage-okban, adatvesztés nélkül. De mindig meghibásodik valamelyik, mert statisztikailag pont kijön az, amit kiszámoltál tudományosan.

Otthon 2 diszkkel nagyobb eséllyel fognak elszállni az adataid, mint 1-el, hacsak nem tükrözöd, de nem ez volt az eredeti gondolat, hanem, hogy a rendszer legyen 1 db SSD-n, az adatok meg 1 db HDD-n.

Nem tudom, hogy mi nem tetszik.

--
robyboy

A trendet tekintve igazad van, ezt írtam is. A számszerűsítéssel volt bajom. Kétszer annyi disk nem kétszer akkora meghibásodási valószínűséget jelent szerintem. Érzékelhető szemléletből is az ellentmondás: 100 % fölé nem mehet a meghibásodási ráta, mert már a 100 % is azt jelenti, hogy hiába cserélsz mindent újra, el sem tudod indítani, mert kapásból garantáltan legalább egy lemez rossz.

Azt is írtam, hogy alacsony eszközszám és kis meghibásodási valószínűség esetén viszont jó közelítés, hogy n-szer annyi lemez n-szeresére növeli a meghibásodás valószínűségét. Ez amolyan munkaponti linearizálás. Szűk tartományban jó közelítés, de általánosságban nem igaz.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ah ok. Igazából az "x" helyett kellett volna "db"-ot írnom, úgy is gondoltam. Szóval egy db 50% helyett 2 db 50%, ha 2 diszkröl beszélünk. Nem úgy gondoltam én sem, hogy 2 diszknél egyböl elromlik valami.

--
robyboy

Meg úgy nagyjából bármit - ha ért hozzá az ember... Nekem a korábbi gépen a C: az OS és a legfontosabb (leggyakrabban használt) alkalmazásoké volt, a D: meg a profilokat (aka "/home") illetve a ritkábban használt lomokat tartalmazta, még XP-t használva. Az első (OS) diszk szólóban ment (ntbackup tette a dolgát rendszeresen), a másik meg két diszkre tükrözött dinamikus köteten csücsült (igen, XP és tükrözött dinamikus kötet - csak néhány megfelelő bájtot kellett itt-ott átírni...), úgyhogy onnan csak a kifejezetten fontos adatok kerültek külső diszkre kimásolásra. A Win7/10 is hasonlóan lett összerakva, köszönik, jól elvannak...

Ja, és ez az olvasási teljesítményre is elég jótékonyan hat - mivel döntően olvasásra használom a diszkeket, nem írásra, így a gyengébb írási teljesítmény nem releváns a számomra.

Logikailag lehet megkérdőjeleződik, de a gyakorlatban hidd el, hogy lehet értelme. A Windows alap cache-elése nagyon ergya, nem sokat ér sajnos. Nem tudom mi lehet az oka, ennyire mélyen nem ismerem, szerintem csak spórolós a cache-elése, nem mer sok memóriát használni hozzá, mert ahogy írod, valószínű valami átlagsebességes közbülső bufferértékkel dolgozik. A RAM disk szoftver meg annyit használ, amennyit mondasz neki.

Annyiból igazad van, hogy egy normálisan megírt OS alatt nem lenne szükség ilyen RAM drive-os csodákra, Linux alatt sincs szükség ilyenre, ott a kernel normálisan cache-el, amíg van bőven szabad RAM. Már pedig nálam pl. a 16 giga DDR3-nak a nagy része mindig szabad, és meg is látszik, mert ilyen dd-s teszteken ilyen 6,8 GB/sec-es értékek jönnek ki, mikor csak SATA3-as SSD van a gépben. Minden cache-ből megy, a kernel csak akkor írogatja ki a fizikai meghajtóra, ha annak nincs épp nagy I/O terhelése, szépen kicsöpögteti, de olyan kíméletesen, hogy a lemezműveleteket jelző LED-et is alig látni felvillanni. Így meg a programok betöltési ideje a legtöbb esetben 0-nak érződik, és a fájlműveletek nagy része is pillanat műve (nem nagyon mozgatok 8 gigánál nagyobb fájlokat). Ezt a szintet a Windows alapból nem tudja hozni, csak spéci szoftverrel.


No keyboard detected... Press F1 to run the SETUP

A fentiekhez: Egy számomra érdekes technikai problémával fordultam hozzátok, amihez kaptam segítséget is, köszönöm.

Amit nem tudok hova tenni, az a kommentek többsége, ami viszont nem a felvetéssel foglalkozik (ami a körülményektől függetlenül szerintem izgalmas téma), hanem a munkahelyemmel, és az ssd-vel. Oké, tényleg valid tanács, hogy ssd-vel illene bővíteni. De miután ezt leírtam, elmondtam hogy miért nem játszik most, miért jön még többszáz (túlzás) komment a témában? Miért mondtok véleményt a munkahelyemről a körülmények ismerete nélkül? Jó munkahelyem van, király a fizetésemmel, és megannyi jóság van, ami mellett eltörpül az, hogy a géppark kicsit le van maradva. Apró hiányosság, mindenhol van ilyen, max másban nyilvánul meg.

Plusz ha nekem bővítenek, akkor bővíteni illene a másik száz? gépnél is. Máris nem 10e forintról van szó. Ráadásul ki akarná megvenni hosszútávra, munkára a legolcsóbb, legkisebb SSD-t?

Akkor viszont még ma rendelj meg egy SSD-t, holnap hazafelé hozd el a boltból, csütörtökön rakd a gépedbe. Kevesebb idő megy vele az életedből, mint az ezen pörgéssel a fórumon. ;)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ha a cég fix összeggel vállal projekteket, akkor megveszik az ssd-t, mert a lassúság miatt lassabban haladsz és kevesebbet termelsz. Ha a cég órabérben dolgozik, akkor nem kapsz ssd-t, nem kell sietni. Ha saját projekteken dolgozik, akkor valami nagyon jó más bevételi forrása lehet, hogy nem cél a gyors munkavégzés, mondjuk fióknak készülő eu pályázatokon :D
Simán extrapoláljuk két információmorzsából a jövődet, https://xkcd.com/605/ :D

Kértem én jövendőmondást, és rosszindulatú kommenteket? Nem :)

ingyen van:)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Nálunk pl. többen úgy csinálták, hogy saját pénzen tettek a laptopjukba SSD-t, aztán amikor le kellett adni a laptopot, akkor kivették, és otthonra még jó volt. (Az ilyesminek én elvileg ellene vagyok, de embere válogatja). A lecserélt új laptopok pedig már eleve SSD-vel jöttek.

Ezt csináld meg egy nagyobb cégnél. Az usb port is csak befele enged, nem hogy ne lenne leplombázva a géped és oldalnyitásra küldi is a jelet hálózaton :) Persze a gép beszerzés is központosított, így jobb esetben már három év után le is cserélik - persze az új - és nagy étvágyú - programok azok kellenek, mert haladjunk a korral, így gyak. a "fejlődéssel" egyre lassulunk. De ha nekik így jó.... ;P

Bátorítalak, a ramdisk nem csak a SATA de a PCIe/NVMe SSD-k sebességéhez képest is sokkal gyorsabb, szekvenciális és random R/W-ben is. Pár éve, mikor még programoztam, nálam az Intellij Idea system és log folderei mentek egy ramdiskre, illetve a chrome cache. A cpu lehetővé tette hogy ecc RAM volt a gépekben, és szünetmentesre voltak téve, adatvesztéstől annyira nem tartottam. A ramdisk szoftvercsomagban volt konfiguráló utility, ott be lehetett állítani hogy bootkor automatikusan jöjjön létre a ramdisk, mountolódjon, és meg lehetett neki adni egy imaget amiben mentette és visszatölötte az állapotát. Fontos fájlokat sosem tettem ramdiskre. Szóval a teljes projekteket én nem raknám ramdiskre, de IDE munkakönyvtárak, böngésző cache stb mehet szerintem.