2kpl erillisiä Samsung ssd-levyjä vai käyttis ja media samalle levylle mutta eri osioille?

[Petewal]

Tällä hetkellä Win8.1 htpc-koneessani on käyttöjärjestelmä Samsung EVO 850 256Gb ssd:llä ja kaikki kuvat/musat/pelit erillisellä WD Red 3Tb hdd:llä.

Nyt olen korvaamassa 3Tb WD kovalevyä Samsung EVO 860 4Tb ssd:llä niin onko jotain etuja tai haittoja jos vaan yksinkertaisesti peilaan kovalevyn sisällön ssd:lle ja jätän tuon vanhemman 850 evon käyttöjärjestelmälle.

Toinen vaihtoehto olisi että voisin vaikkapa tuosta uudesta 4Tb ssd:stä osioida käyttöjärjestelmälle vaikkapa tuon saman 256Gb ja loput jättäisn medialle, jolloin voisin hukata tuon aiemman 850 evon.

Tuleeko kenelläkään mitään hyötyä/haittaa mieleen, kumpi järkevämpi yksi vai 2 ssd-levyä?

 

[hsalonen]

SSD:n osioimisessa ei ole yhtään mitään järkeä.

Jätä vaan vanha levy käyttöjärjestelmälle.

 

[E.T]

SSD:n osioimisessa ei ole yhtään mitään järkeä.

Kyllä käyttöjärjestelmälle nyt kannattaa aina oma osionsa olla, siltä varalta että se vääntää itsensä umpisolmuun.
Paljon helpompaa jyrätä käyttisosio, kun sillä ei ole muita datoja.

Mutta tosiaan ei sitä kannata ruveta (t)uhraamaan aikaa ja vaivaa käyttöjärjestelmän siirtämiseen.
Ellei sitten esim. Samsungin työkalu näytä että vanha levy olisi merkittävästi kulunut.

 

[Petewal]

Kiitokset hsalonen ja E.T infosta Sen verran pessimisti kyllä olen että haluan pitää käyttöjärjestelmän erillisenä muusta että jos tulee ongelmia niin voin asentaa käyttiksen uusiksi joko omalle osiolle tai sitten täysin eri ssd:lle ja media ei vaarannu. No tuo vanhempi Samsung 850 kyllä suht uuden karhea joten taidan jättää käyttiksen sit sille. Ajattelin vaan onko mitään eroa tai varsinkin hyötyä siitä onko käyttis erillisellä levyllä vaiko yhden saman levyn eri osiolla.

 

[vemkki]

Kiitokset hsalonen ja E.T infosta Sen verran pessimisti kyllä olen että haluan pitää käyttöjärjestelmän erillisenä muusta että jos tulee ongelmia niin voin asentaa käyttiksen uusiksi joko omalle osiolle tai sitten täysin eri ssd:lle ja media ei vaarannu. No tuo vanhempi Samsung 850 kyllä suht uuden karhea joten taidan jättää käyttiksen sit sille. Ajattelin vaan onko mitään eroa tai varsinkin hyötyä siitä onko käyttis erillisellä levyllä vaiko yhden saman levyn eri osiolla.

Onhan erillisillä levyillä varmaan teoriassa parempi suorituskyky, kun molempia asemia voidaan käyttää samaan aikaan, mutta käytännön hyöty taitaa olla vähän niin ja näin, kun on SSD-asemista kyse.

 

[Threadripper]

Kiitokset hsalonen ja E.T infosta Sen verran pessimisti kyllä olen että haluan pitää käyttöjärjestelmän erillisenä muusta että jos tulee ongelmia niin voin asentaa käyttiksen uusiksi joko omalle osiolle tai sitten täysin eri ssd:lle ja media ei vaarannu. No tuo vanhempi Samsung 850 kyllä suht uuden karhea joten taidan jättää käyttiksen sit sille. Ajattelin vaan onko mitään eroa tai varsinkin hyötyä siitä onko käyttis erillisellä levyllä vaiko yhden saman levyn eri osiolla.

On siitä käyttiksen pitämisestä omalla levyllä aina hyötyä, koska käyttistä luetaan tai kirjoitetaan usein samaan aikaan kuin ohjelmille tehdään samaa.

 

[hsalonen]

TRIM toimii huonommin, kun se ei saa allokoida tyhjiä blokkeja tasaisesti koko levyltä. Levyn write amplification nousee, eli sinne tiettyyn pieneen osioon kirjoitetaan enemmän ja jokaisella SSD-levyllä on rajoitetut kirjoituskerrat.

 

[Threadripper]

TRIM toimii huonommin, kun se ei saa allokoida tyhjiä blokkeja tasaisesti koko levyltä. Levyn write amplification nousee, eli sinne tiettyyn pieneen osioon kirjoitetaan enemmän ja jokaisella SSD-levyllä on rajoitetut kirjoituskerrat.

Kestävyyden kannalta noin. Nopeuden kannalta toisin.

 

[HekaDesimaali]

Mitekäs olikaan .... Win 8.1 ja boot osion max 2 Tb ja loppulevyä ei voi käyttää mihinkään ... muistelenkohan olemattomia ... liittyykin siihen MBR ja GPT teknologian valintaan ... ongelmaahan ei tule, jos on boot omalla levyllään ;-)

 

[MMXVI]

TRIM toimii huonommin, kun se ei saa allokoida tyhjiä blokkeja tasaisesti koko levyltä. Levyn write amplification nousee, eli sinne tiettyyn pieneen osioon kirjoitetaan enemmän ja jokaisella SSD-levyllä on rajoitetut kirjoituskerrat.

Mihin blokkien allokointiin tässä nyt oikein viittaat?

 

[hsalonen]

Mihin blokkien allokointiin tässä nyt oikein viittaat?

Tyhjien. Kannattaa opetella, miten SSD toimii.

Write amplification - Wikipedia

 

[Loisteho]

Tyhjien. Kannattaa opetella, miten SSD toimii.

Write amplification - Wikipedia

Eikös blokkien fyysisen allokoinnin hoida SSD:n ohjain, joka on autuaan tietämätön osioinnista? Jos jotain tiedostoa kirjoitetaan tuhansia kertoja uusiksi, ei se tapa kyseistä solua levystä, vaan ohjain heittää uudet kirjoitukset aina uuteen fyysiseen osoitteeseen, minkä sijaintia ei osiointi rajoita mitenkään.

 

[hsalonen]

Eikös blokkien fyysisen allokoinnin hoida SSD:n ohjain, joka on autuaan tietämätön osioinnista? Jos jotain tiedostoa kirjoitetaan tuhansia kertoja uusiksi, ei se tapa kyseistä solua levystä, vaan ohjain heittää uudet kirjoitukset aina uuteen fyysiseen osoitteeseen, minkä sijaintia ei osiointi rajoita mitenkään.

Tämä onkin mielenkiintoinen keskustelu, mutta ainakin TRIM toimii käyttöjärjestelmätasolla, levyn osioita kunnioittaen.

Teoriani oli, että myös tyhjien blokkien allokointi nappaisee uudet blokit sieltä osiosta, kun se on kuitenkin määrätty tiettyyn osaan levyä.

Kai tämä on siitä kiinni, kuinka fiksu ohjain siellä on taustalla. Niin monta kertaa olen pettynyt, kun olen olettanut jonkun vain osaavan tehdä asiat oikein, että en enää oleta..

 

[Loisteho]

Tämä onkin mielenkiintoinen keskustelu, mutta ainakin TRIM toimii käyttöjärjestelmätasolla, levyn osioita kunnioittaen.

Teoriani oli, että myös tyhjien blokkien allokointi nappaisee uudet blokit sieltä osiosta, kun se on kuitenkin määrätty tiettyyn osaan levyä.

Kai tämä on siitä kiinni, kuinka fiksu ohjain siellä on taustalla.

Ohjaimen wear-leveling ei voi edes olla tietoinen osioinnista, koska osiointi ei ole käytännössä kuin tiedosto levyn alussa, joka kertoo tiedostojärjestelmälle miten levyä käytetään. Tiedostojärjestelmä puolestaan on konsepti josta SSD:n ohjaimella ei ole mitään käsitystä, eikä SSD:llä voida myöskään osoittaa fyysisiä blokkeja. ZFS:ään SSD-välimuistia rakennellessa nimenomaan suositeltiin, että osioi levyn ja jättää sinne suuren tyhjän osion (joko osioimaton, jolloin alustaessa käyttis kertoo blokkien olevan vapaita, tai osioitu ja ajaa komennon blokkien vapaaksi merkkaamiseksi), koska silloin levyohjain tarvittaessa allokoi sieltä uusia blokkeja ja levy kuluu tasaisemmin. TRIM toimii käyttöjärjestelmätasolla, mutta levyohjaimessa on vielä oma kerroksensa joka vaihtelee noita fyysisiä sijainteja. TRIM "kunnioittaa" osiointia siten, että se ei merkkaa toisella osiolla olevia blokkeja vapaaksi itsestään, vaan osiokohtaisesti.

Pitää joku päivä kokeilla tuota ihan käytännössä, nurkissa pyörii yksi ylimääräinen kymmenen vuoden ikäinen SSD, joku megatavun kokoinen osio siihen ja kirjoittaa sinne (kymmeniä) tuhansia kertoja ja katsoo alkaako data korruptoitumaan.

 

[hsalonen]

Ohjaimen wear-leveling ei voi edes olla tietoinen osioinnista, koska osiointi ei ole käytännössä kuin tiedosto levyn alussa, joka kertoo tiedostojärjestelmälle miten levyä käytetään. Tiedostojärjestelmä puolestaan on konsepti josta SSD:n ohjaimella ei ole mitään käsitystä, eikä SSD:llä voida myöskään osoittaa fyysisiä blokkeja. ZFS:ään SSD-välimuistia rakennellessa nimenomaan suositeltiin, että osioi levyn ja jättää sinne suuren tyhjän osion (joko osioimaton, jolloin alustaessa käyttis kertoo blokkien olevan vapaita, tai osioitu ja ajaa komennon blokkien vapaaksi merkkaamiseksi), koska silloin levyohjain tarvittaessa allokoi sieltä uusia blokkeja ja levy kuluu tasaisemmin. TRIM toimii käyttöjärjestelmätasolla, mutta levyohjaimessa on vielä oma kerroksensa joka vaihtelee noita fyysisiä sijainteja. TRIM "kunnioittaa" osiointia siten, että se ei merkkaa toisella osiolla olevia blokkeja vapaaksi itsestään, vaan osiokohtaisesti.

Pitää joku päivä kokeilla tuota ihan käytännössä, nurkissa pyörii yksi ylimääräinen kymmenen vuoden ikäinen SSD, joku megatavun kokoinen osio siihen ja kirjoittaa sinne (kymmeniä) tuhansia kertoja ja katsoo alkaako data korruptoitumaan.

Fyysisinä blokkeina/sektoreina nuo tuolta kuitenkin varataan käyttöjärjestelmätasolla, koska pitää olla taaksepäinyhteensopivia kovalevyjen kanssa. Tosin juu, SSD voi sisäisesti mapata noita miten tuntuu..

Ehkä minulla on turhan pessimistinen kuva kontrollerista ja sen kyvykkyydestä, mutta pessimisti ei pety.

--

Jos vanha levysi on kahden potenssi, tässä testissä on järkeä. Jos ei, niin noita kuolleita sivuja voidaan siirtää sinne allokoimattomalle alueelle, jonka koko on vaikka 128Gt:n SSD:ssä 8Gt.

 

[E.T]

Fyysisinä blokkeina/sektoreina nuo tuolta kuitenkin varataan käyttöjärjestelmätasolla, koska pitää olla taaksepäinyhteensopivia kovalevyjen kanssa. Tosin juu, SSD voi sisäisesti mapata noita miten tuntuu..

Se taaksepäin yhteensopivuus tapahtuu ohjaimen tekemällä emuloinnilla.
Mitkään tiedostojärjestelmätason osoitteethan eivät SSD:ssä linkity mihinkään kiinteään fyysisessä sijainnissa olevaan osoitteeseen, ohjaimen heitellessä dataa eri sijainteihin oman logiikkansa mukaan.

Eihän se over-provisioningkaan voisi auttaa wear leveling algoritmeja, jos ohjain kunnoittaisi jotain tiedostojärjestelmän rajoja.
SSD | Understanding Over-provisioning (OP)
SSD Over-Provisioning And Its Benefits | Seagate UK
Eli ohjaimen on kyettävä käyttämään tiedostojärjestelmän osioinnin ulkopuolista tilaa.

 

[MMXVI]

Kuulostikin siltä että puurot ja vellit on nyt hieman sekaisin.

Tämä onkin mielenkiintoinen keskustelu, mutta ainakin TRIM toimii käyttöjärjestelmätasolla, levyn osioita kunnioittaen.

A trim command (known as TRIM in the ATA command set, and UNMAP in the SCSI command set) allows an operating system to inform a solid-state drive (SSD) which blocks of data are no longer considered in use and can be wiped internally.

TRIM ja wear leveling ovat oleellisesti eri asioita. Vaikka TRIM vaatii tuen myös käyttöjärjestelmältä, se ei toimi yksinomaan käyttöjärjestelmän tasolla. TRIM on pohjimmiltaan vain mekanismi jolla OS välittää levyn firmwaren ja kontrollerin käyttöön tiedon siitä mitkä blokit levy saa tyhjentää oman harkintansa mukaan. Tarkoitus on roskienkeruuta tehostamalla paitsi parantaa suorituskykyä, myös tukea wear levelingin toimintaa maksimoimalla vapaiden käytettävissä olevien blokkien määrä.

Teoriani oli, että myös tyhjien blokkien allokointi nappaisee uudet blokit sieltä osiosta, kun se on kuitenkin määrätty tiettyyn osaan levyä.

Tämä ei nähdäkseni pidä paikkaansa. Kuten Loisteho yllä jo ansiokkaasti selvensi, wear leveling on levyn sisäinen toiminto joka on abstraktiotasolla huomattavasti alempana, eikä levyn firmware tiedä saati välitä yläpuolellaan olevista tiedostojärjestelmistä tai partitioista.

ZFS:ään SSD-välimuistia rakennellessa nimenomaan suositeltiin, että osioi levyn ja jättää sinne suuren tyhjän osion (joko osioimaton, jolloin alustaessa käyttis kertoo blokkien olevan vapaita, tai osioitu ja ajaa komennon blokkien vapaaksi merkkaamiseksi), koska silloin levyohjain tarvittaessa allokoi sieltä uusia blokkeja ja levy kuluu tasaisemmin.

Tässä puhutaan mitä ilmeisimmin yliprovisioinnista, joka taitaa olla käytännössä kaikissa nykyisissä levyissä sisäänrakennettu feature. Esim. Samsungin levyt tulee tehtaalta 7% yliprovisioinnilla, jolloin 7% kapasiteetista on rajattu wear levelingin tarpeisiin eikä näy lainkaan käyttöjärjestelmälle. Ainakin vielä pari vuotta sitten provisioinnin määrää pystyi myös tarvittaessa itse säätämään mieleisekseen Samsung SSD Magician-softalla.

 

[hsalonen]

Pitäisiköhän meidän etsiä joku toinen ketju tälle väittelylle?

En kyllä enää rupea kirjoittamaan käyttämiäni termejä auki ja jos niiden käyttö sekaisin aiheuttaa jollekin sekaannuksia, niin se on voi voi. Taisin viikon yrittää murossa, mutta nyt en enää jaksa. Jos puhun TRIM:istä, tarkoitan TRIMiä. Jos puhun write amplificationista, se on tarpeeksi lähellä wear-levelingiä, että voitte rinnastaa ne. Mutta kaikesta ei voi vetää kausaliteettiviivaa.. Over provisionista olen puhunut yhdessä lauseessa edellisessä viestissäni (se viimeinen lause).

 

[MMXVI]

Jos puhun write amplificationista, se on tarpeeksi lähellä wear-levelingiä, että voitte rinnastaa ne.

Tyydyn toteamaan että nämäkin ovat teknisesti ottaen kaksi eri asiaa.

 

[hsalonen]

Voi perkele.

No, yhteenvetona:
Jos @hsalonen on väärässä kaikessa, niin käyttöjärjestelmälevyn voi ihan suosiolla laittaa omalle osiolle samalle levylle. Täällä käsitellyistä asioista ei ole mitään haittaa ja kaikki toimii 100% ja nopeasti.
Jos kontrolleri ei ole niin fiksu, niin kestävyys (durability) kärsii. En voi varmasti sanoa, eikä kukaan muukaan voi, kun sen toiminta ei ole julkista. Pessimistinä oletan pahinta. Vahvasti kyllä 2-3 henkilöä yrittää vakuuttaa, ettei näin ole.

--

Kukaan ei myöskään ole sanonut, että siitä kahdesta levystä on mitään haittaa. Ei siitä ole. Ainoastaan, jos vanha levy on kulunut, se kannattaa päästää eläkkeelle, niinkuin sanottiin. Levyn kuntoa voi katsoa tällä ohjelmalla:
CrystalDiskInfo
(ja eiköhän SSD Magician näytä sen myös)

 

[Petewal]

Kiitokset kaikille asiaa kommentoineille ja sen verran itseltä meni yli hilseen suurin osa että uskon että helpointa on vaan kloonata media hdd kokonaisuudessaan suoraan uudelle isommalle ssd:lle.

HekaDesimaali:n kommentista muistui mieleen että käyttämäni Fujitechin Clone Deck taisi kloonata levyt siten että tekee samankokoisen osion uudelle levylle ja lopputila jää piiloon käyttämättömäksi. Muistelen että sain sen jollakin ohjelmalla joskus aiemmin liitettyä takaisin näkyväksi ja siten laajennettua samaan osioon, oliko nykyjään joku suositeltava ilmaisohjelma toimenpiteeseen?

 

[topiv]

HekaDesimaali:n kommentista muistui mieleen että käyttämäni Fujitechin Clone Deck taisi kloonata levyt siten että tekee samankokoisen osion uudelle levylle ja lopputila jää piiloon käyttämättömäksi. Muistelen että sain sen jollakin ohjelmalla joskus aiemmin liitettyä takaisin näkyväksi ja siten laajennettua samaan osioon, oliko nykyjään joku suositeltava ilmaisohjelma toimenpiteeseen?

Itse olen käyttänyt temppuun ohjelmaa nimeltä
EaseUS Partition Master Free Edition

Tässä linkki vastaaviin ohjelmiin arvosteluineen.

 

[Spartacus]

Itselläni on tällä hetkellä useampi vanhahko SSD levy ja ajattelin ostaa yhden uuden joka korvaa muut. En ole edes ajatellut, että SSD:n osioimisella olisi jotain merkitystä ja se ei taas missään tapauksessa tulo kuuloonkaan että koneessa olisi vain C:-asema.

Pitääkö tässä nyt ostaa kaksi uutta levyä, yksi pienehkö käyttikselle ja iso muulle datalle

 

[vemkki]

HekaDesimaali:n kommentista muistui mieleen että käyttämäni Fujitechin Clone Deck taisi kloonata levyt siten että tekee samankokoisen osion uudelle levylle ja lopputila jää piiloon käyttämättömäksi. Muistelen että sain sen jollakin ohjelmalla joskus aiemmin liitettyä takaisin näkyväksi ja siten laajennettua samaan osioon, oliko nykyjään joku suositeltava ilmaisohjelma toimenpiteeseen?

Jos loppuosa levystä on käyttämättä, niin ihan Windowsin omilla työkaluilla voi kyllä suurentaa partitiota.
https://www.howtogeek.com/101862/ho...ndows-without-downloading-any-other-software/

 

[Melbac]

Itse huomannut että paljon helpompaa että yksi levy on systeemilevy ja muilla sitten ne muut jolloin voi vaan ottaa ne muut levyt irti ja pistää windows ihan uusiksi sille systeemilevyllä.Se systeemilevy on tietenkin levyistä nopein jos noita nyt sattuu olemaan eri ikäisiä ja nopeuksisia.Ei tule ainakaan pelkoa että menee deletoimaan jotain.Tossa tosin voi joutua asentelemaan jotain softia uusiksi mutta siinä ei kauan mene jos on vielä modannut sen asennus imagen ns "melkein valmiiksi".Windows nyt on muutenkin nopeampi asentaa uusiksi kuin alkaa säätämään vanhaa asennusta jos joku menee vikaan omien tai softien säätöjen takia.

/offtopic
Se systeemilevy kannattaa sitten olla tarpeeksi suuri että sinne mahtuu esim jotain pelejä/muita softia.