[kaabakas]

Äkki meil oleks vaja juurde teemat KÕVAKETTAD (SSD) - Statistika, Võrdlus, Testid, Soovitused, Info

[napoleon]

Pigem teema pealkirja muuta kui see HDD eksitav on.

[kaabakas]

Ega keerlevaid kettaid ka kodutuks jätta ei saa.

[Raivoy]

Minu viga, et see tähelepanuta jäi, et tegu pigem HDD suunitlusega teemaga. Vabandan.
Tundus ka pisut imelik uus teema teha.

Natuke teemasse küsimus.
Kas 2,5" IDE ketastega on veel midagi teha tänapäeval? Mul vist seisab riiulis veel 2tk selliseid.

[napoleon]

No võid pakkuda näiteks siin grupis https://www.facebook.com/groups/636411413155737
vbl. keegi tahab mõne vanakese nii elustada, et oleks ajastutruu.
Üldiselt 2,5" HDD-l mingit suuremat kasutusväärtust pole kuigi entusiastide seas võib huvilisi leiduda.

[karuke]

Uurin NAS ketaste kohapealt, 4-bay QNAP NAS'i jaoks vaja 1 lisa ketats. Raid 5'es jookseb.
Hetkel on 3 x WD30EFZX-68AWUN0 (Sisuluselt hetkel siis WD Red PLUS 3TB seeriaga võrdsed)

Mõtlesin, et võtan neljandaks kettaks midagi suuremat, et hiljem kui need 3TB teised välja vahetan on lihtsam. AGA 4Tb WD PRO on sisuliselt sama hinnaga, mis Plus, seega kas oleks mõistlik ikkagist see 4Tb PRO võtta.

3TB PLUS - link
4Tb PRO - link

--- Edit ----
Ei tea kuidas ma selle PLUS urli nii vale panin ok natuke odavam on.

[kaabakas]

Red plus, pro, kodukasutuses vahet pole. Peaasi et smr kettad ei ole.
Aga 3T->4T upgradel küll mingit mõtet ei ole. Kui ruum hakkab lõppema, on järgmine samm kaks või kolm korda rohkem ruumi.

[Longero]

karuke, su enda esimeselt lingilt tuleb ca $18 saatekulu juurde, see USA Amazon. Vaata, seal paremal hinna all kirjutatud.

[napoleon]

Red plus on aeglasem, aga väidetavalt vaiksem kui müra oluline on.
Mul endal on NAS-s üldse WD Ultrastar, natuke lärmakam, aga Eestist ostes odavam kui Red Plus ja muudelt parameetritelt parem.
Tõsi, mul on 20TB kettad, pisikeste puhul võivad hinnad muud pidi varieeruda.

3TB või 4TB puhul juba mõtleks SSD peale hoopis.

[karuke]

SSD'd on ikka pea 2,5x kallimad sama mahu juures.

Maybe siis 6TB WD RED Plus. Või analoogne Ironwolf ...

Just vaatasin tarneajad on pikad osad miski 2026, kas miski RED seeria kriis või mis toimub??

FREE delivery 28 November, 2025 - 11 April, 2026

[Longero]

Ma võtaks ka 6TB ja vaiksed 5400rpm kettad kui mahtu palju vaja pole.
Mingi ca kuu vms tagasi olid odavamad.
karuke, v kui arvad, et 4TB kettad su jaoks piisava mahuga siis miks mitte. Kõik oleneb inimese vajadusest.
Muidugi pead algsest mahust maha arvama partitsioneerimise kaod + mõistlik vaba ruumi vajadus.

[Tomorrow]

[napoleon]

[Dirty Harry]

Minu praktika on olnud osta järelturult mõistlikult kasutatud HDD'd usaldusväärselt müüjalt ja luua omale 3-2-1 backupi süsteem: andmetest on kolm versiooni, neist vähemalt kahel erineval meediumil (arvuti, NAS, pilv vmt) ja üks koopia on füüsiliselt kusagil kaugemal. Ning kui on nii tehtud, siis on laias laastus igalpool JBOD, pole RAIDi vajanud.

St mu strateegia on olnud - mitte liiga palju panna lokaalse dubleerimise ja tõrkekindluse peale vaid pigem on asju mitmes kohas. Võib muidugi ka RAIDi lisada, see on juba selline personaalne eelistus.

[napoleon]

Kuidas suuremad datacenterid HDD ketastega toimetavad, kas vahetavad välja siis kui RAID-s üks maha sureb või on ka mingi tavaprotseduur et n aasta tagant vahetavad profülaktika mõttes välja kui enne otsi pole andnud?

[kaabakas]

Ei hakka keegi töötavat asja parandama. Võita pole midagi, küll aga kaotada.

[udumees]

[Longero]

Palju siinolijaist oma uut andmeketast formaatides klastri suuruse vaikeseadetest 4096 (4KB) suuremaks olete pannud? Win ju ei tea mis te sinna panna tahate ja segapudru jaoks oleks vbla jah 4096 (4KB) parim valik .
Mul 8 TB ketas, teeks midagi sellist, ca 2TB muusika jaoks ja ülejäänu ca 5 TB filmide jaoks. 64K on Win 7 enda max võimalus disk management'ist vaadates, kindluse mõttes teeks Win 7 enda omaga ja paneks sellesama 64K.
Ok, neisse kaustadesse tuleb ka väiksemaid faile nagu kaanepildid, subtiitrid jne, aga tänapäevaste kettamahtude juures mõned GB ruumikadu pole oluline.

https://superuser.com/questions/31682/what-allocation-unit-size-should-i-use-for-a-drive-with-a-single-ntfs-partitio

[Tomorrow]

Niipalju kui ma minevikus selle klastri suuruse kohta uurisin oligi nõuanne, et enamus juhtudel tasub kasutada default, ehk mitte ise muuta.
Mingites oludes ilmselt väike suurus on kasulik hulga väikeste failide puhul ja suur suurte failide puhul.
Segafailide puhul jälle default.

Ma loogiliselt eeldaks, et see on olulisem kuskil serveris paljude ketastega. Kahtlen, et kodukasutajal käputäie ketastega mingit tunnetatavat vahet on kui ei kasuta just igivana proset.

[Longero]

Tegin sellele 8TB Toshiba MG08ADA800E pika formati. Aega läks ca 15-16 tundi. Vahel nagu tundub, et mõned kettad teevad kiiremini ära (aeg TB kohta).
Läks siis igaksjuhuks kindluse mõttes 4096 (4KB) klastriga.

[kaabakas]

Põhjusmõtteliselt on kaks asja, mida sa klastri suurusega tuunid.

Esiteks, 4k klaster on selles suhtes hea, et klapib mälulehe suurusega, ja seega on kettalt mällu laadimine 1:1 tegevus ilma ümber lappamiseta. Kuna aga mälu on kettast tuhat korda kiirem, ja prose mälust omakorda tuhat korda, siis see ümber lappamine sisulist rolli ei mängi.

Teiseks, suuremat klastri suurust kasutades on võimalik vähendada failide fragmenteerumist - tagada, et neid kirjutatakse (ja hiljem loetakse) pigem järjestikku ühte kohta, mitte juhuslikult igale poole laiali. Kuigi ssd pidi meid vabastama fragmenteerumise jõudlusprobleemidest, on reaalsus see, et iops on jätkuvalt reaalne pudelikael. Teoreetiline kiirusevõit juhulugemise/kirjutamise asemel järjestikku lugemisel/kirjutamisel on 100x. Aga. Kaasaegsed failisüsteemid on piisavalt arukad, et piisava vaba ruumi olemasolul suuri faile mitte fragmenteerida, ja lisaks, nende lõppu veel vaba ruumi jätta, et kui andmeid veidi lisanduma peaks, siis fail jätkuvalt ühes kohas koos oleks.
Tulemus on see, et klastri suurusega mängimisest palju rohkem kasu on lihtsalt sellest, et sa ketast ääreni täis ei kirjuta, nõnda saab failisüsteem neid asju ise ära korraldada.


Tradeoff suurema klastri juures on tõesti see, et väikesed failid suurte klastrite peal raiskavad ruumi. Aga see pole ka päris ammendav probleemikirjeldus. Fail ei saa tõesti kettal vähem ruumi võtta kui üks klaster. Nii et 1k fail 1M klastritega failisüsteemis võtab tõesti 1M ruumi. Aga probleem laiemalt seisneb selles, et fail ei saa kettal ruumi võtta muud moodi, kui täisarv klastreid. Seega sama mure jääb alles ka suurematel failidel. 1,001M fail võtab 2M ruumi. 10,001M fail võtab 11M ruumi. Filmikollektsiooni gigaste failide juures ei pane tähele, aga mp3- või fotokollektsiooni paarimegaste failide juures oleks megane klaster juba korralik raiskamine.

Kaasaegsemad failisüsteemid muidugi oskavad teinekord peenemaid ruumi säästvaid lähenemisi, nagu väikese faili kirjutamine otse inodesse ilma salvestusklastrit kasutamata, või siis mitme väikese faili või failipära ühte klastrisse kokku kirjutamine. Ntfs mini mälu järgi kumbagi ei tee. Eks ta on oma põhiolemuses ka ürgvana praeguseks. Kui kolmanda osapoole kettautikad huvi pakuvad, siis ma hoiaks ntfs settingud kõik defaulti peal, sest need utikad on suht metsik lääs, ja keegi ei tea ennustada, milliseid alusetuid eeldusi nad asjade kohta teevad, ja mille peale püksid täis lasevad.

Teine teoreetiline tradeoff klastri suuruse juures on see, et suuremaid klastreid on kettal kokku vähem, ja nende üle arve pidamine võtab vähem mälu ja kettaruumi. Reaalsuses see sisulist rolli ei mängi, kui me deduplitseerima ei hakka.


Kodukasutaja filmi- ja muusikaladude jaoks on kogu see teema tõepoolest tarbetu. Isegi pöörleva ketta 100-150 iopsi on täiesti piisav, et filmid ja muusika sealt pealt ilma probleemideta maha mängida või kopeerida. Parim optimeerimine mida sellisele teha, on teinekord pärast suuremat laamendamist defragmenti jooksutada, ja kui ketas nii 80-90% täis on, suurema vastu vahetada.

Serverite puhul on optimeerimisel veidi rohkem jumet. Kui klientide hulk masina otsas ketta iopse umbe hakkab tõmbama, siis saab tõesti vaadata, kas faile on võimalik suuruse või olemuse järgi paremini hallata. Näiteks andmebaasidest, mis ennast sisemiselt 8k või 16k kaupa organiseerivad, on tõesti võimalik plokisuurust sellele vastavaks tuunides iopside hulka vähendada ja seeläbi kettast rohkem välja pigistada. Aga nagu ennegi, siis failisüsteem saab sellega tegelikult iseseisvalt ka päris hästi hakkama, peaasi et tal nii palju vaba ruumi on, et ta klastrite välja jagamisel säästurežiimile ei lähe. Käsitsi tuunimisega liiga palju võita ei ole, küll aga on võimalik asju hoopis hullemaks teha. Tarvis on süveneda, testida, ja monitoorida. Enamasti on umbes serveriketaste puhul mõistlik kettaid lihtsalt juurde panna. Raid muidugi teeb asjad palju keerukamaks.