Hardware Upgrade Forum

Hardware Upgrade Forum (https://www.hwupgrade.it/forum/index.php)
-   Periferiche di Memorizzazione - Discussioni generali (https://www.hwupgrade.it/forum/forumdisplay.php?f=17)
-   -   SSD: thread generale e consigli per gli acquisti (https://www.hwupgrade.it/forum/showthread.php?t=2575800)


s12a 15-07-2020 18:05

Dovrebbe avere lo stesso hardware del SanDisk Ultra 3D. Uscì un po' prima del Crucial MX500 e dovrebbe essere grossomodo prestazionalmente simile—forse un po' meno rapido in alcuni ambiti ma la differenza è piccola anche nei benchmark.

Non so quali test possa fare in più di quelli già effettuati dai vari recensori all'uscita (anche se principalmente con la versione da 1TB).

https://www.tomshardware.com/reviews...-ssd,5134.html
https://www.anandtech.com/show/11792...1tb-ssd-review
https://www.tweaktown.com/reviews/83...iew/index.html
https://hothardware.com/reviews/wd-b...-3d-ssd-review

Fra parentesi, questo è il "Blue 3D", non il "Blue" e stop. Il secondo è la versione precedente.

@Liupen 15-07-2020 18:12

Quote:

Originariamente inviato da s12a (Messaggio 46882056)
Dovrebbe avere lo stesso hardware del SanDisk Ultra 3D. Uscì un po' prima del Crucial MX500 e dovrebbe essere grossomodo prestazionalmente simile—forse un po' meno rapido in alcuni ambiti ma la differenza è piccola anche nei benchmark.

Non so quali test possa fare in più di quelli già effettuati dai vari recensori all'uscita (anche se principalmente con la versione da 1TB).

https://www.tomshardware.com/reviews...-ssd,5134.html
https://www.anandtech.com/show/11792...1tb-ssd-review
https://www.tweaktown.com/reviews/83...iew/index.html
https://hothardware.com/reviews/wd-b...-3d-ssd-review

Fra parentesi, questo è il "Blue 3D", non il "Blue" e stop. Il secondo è la versione precedente.

Dovresti trovarti bene, specie come affidabilità.

aled1974 15-07-2020 22:10

Quote:

Originariamente inviato da @Liupen (Messaggio 46880988)
L'errore, se a te è venuto di compararli, è però della frase usata nell'articolo... Kioxia non mette in relazione il suffisso Plus con quello PRO di Samsung e soprattutto ne fa un SSD dedicato ai videogiocatori (noi ci metteremmo a ridere di ciò, perchè sappiamo quanto poco valga la cosa).
Exceria PLUS andrà messo in relazione con un Sabrent Rocket e simili.

No, la mia era una critica velata al tipo di analisi agli ssd condotta con un software user friendly volendo giungere a delle conclusioni "forzate". Crystaldiskmark fà quello che ho descritto, e le conclusioni opinabili.

assodato che cdm non è lo strumento migliore, ma se un disco spacciato dal produttore e riportato dal recensore come "senza compromessi" già con un pattern 64gb in cdm mostra il fianco.... :doh:

che sia scritto plus, pro, super, extra, gaming, powa, o quel che è non cambia la sostanza dei fatti: non è un disco "senza compromessi" e siamo in presenza se non di dichiarazioni false per lo meno fuorvianti :read:

chi legge l'articolo pensa che sia un prodotto top (tanto per usare un'altra sigla) ma non è così :boh:


il mio intervento sostanzialmente voleva dire: non credete a tutto quello che leggete, ma informatevi bene prima di acquistare :Prrr:

Quote:

- l'ssd più veloce deve contenere i dati che vengono spostati per lavorare (quindi le librerie, e i file che si elaborano e salvano, estrapolano, ecc ecc)
pertanto se si vuole sata+nvme meglio che l'nvme sia quello dell'OS dove risiederanno anche il programma di manipolazione video e le relative librerie/codecs. Questo anche per poter farci altro col pc intanto che elabora il filmato

ma in questo caso (sata+nvme) vuol dire che rientriamo nella categoria degli amatori, con un paio di spicci in più spesi su un solo nvme pensando che così si stravolga l'esperienza di video editing
(per capirci, di quelli che otterrebbero le stesse cose negli stessi tempi con 2 dischi ssd sataIII)

Quote:

Poi si valuta cosa ci si può permettere come ssd
2 nvme ben vengano ma se no sata+nvme
vero ma meglio nvme+sata ;)


Quote:

Originariamente inviato da Nicodemo Timoteo Taddeo (Messaggio 46881482)
E chi ti dice che non lo faccio già?

Vabbé chiudiamola qui che mi sa che è meglio. :)

sì, forse è meglio :mano:


@ s12a

sandisk-wd stesso disco in tutto e per tutto, sandisk in futuro è probabile che non ne vedremo più

un po' quel che è successo con ocz-toshiba-kioxia

ciao ciao

RobbyBtheOriginal 15-07-2020 22:24

Credo di aver capito dagli ultimi interventi, correggetemi se sbaglio, che per il mio utilizzo (descritto qualche post fa) meglio prendere un nvme per s.o. (a questo punto da 512GB immagino) e tenere il bx200 come dati, insieme ai 2HD uno da battaglia e l'altro da 1TB.

Ora per il modello? Vado di sabrent?

by Tapaparla®©

monster.fx 16-07-2020 00:40

Quote:

Originariamente inviato da s12a (Messaggio 46881822)
Tempo addietro avevo postato riguardo la più-o-meno necessità di acquistare un SSD SATA da 500GB equivalente al Crucial MX500 (ma non necessariamente lo stesso) per installarci sopra un altro sistema operativo da usare per tempi prolungati (non brevi prove e stop).

Alla fine (poco fa) ho ordinato un Western Digital Blue 3D 500GB a 58 euro spedito. Mi arriverà fra qualche giorno.


Ne ho montato pure io uno da 1Tb ad un cliente. La cosa che mi ha sorpreso (in positivo) è la garanzia di 5anni.
Differenze rispetto a MX500 e 860 Evo? Non parlo di prestazioni ai primi utilizzi ma nel tempo.

s12a 16-07-2020 09:52

Quote:

Originariamente inviato da monster.fx (Messaggio 46882417)
Ne ho montato pure io uno da 1Tb ad un cliente. La cosa che mi ha sorpreso (in positivo) è la garanzia di 5anni.
Differenze rispetto a MX500 e 860 Evo? Non parlo di prestazioni ai primi utilizzi ma nel tempo.

In teoria anche il Crucial MX500 ed il Samsung 860 EVO dovrebbero essere garantiti per 5 anni:
https://content.crucial.com/content/...ctflyer-it.pdf
https://www.samsung.com/it/memory-st.../MZ-76E500BEU/

A dire la verità non ho prestato attenzione per nulla a questo particolare, ma la maggior parte degli SSD di fascia più bassa sono garantiti per 2 o 3 anni, dunque la cosa dovrebbe essere positiva.

Credo che però dopo il periodo minimo legale (con cui è meglio vedersela con il venditore) sia spesso una garanzia "sulla carta". Meglio averla, ma probabilmente anche meglio non farci affidamento.

giovanni69 16-07-2020 09:55

Quote:

Originariamente inviato da monster.fx (Messaggio 46882417)
La cosa che mi ha sorpreso (in positivo) è la garanzia di 5anni.

E di questi tempi, con i Samsung QVO a 3 anni :sob: :nonsifa: , è un'ottima cosa.

@Liupen 16-07-2020 12:42

Quote:

Originariamente inviato da aled1974 (Messaggio 46882331)
il mio intervento sostanzialmente voleva dire: non credete a tutto quello che leggete, ma informatevi bene prima di acquistare :Prrr:

Sempre assolutamente :D gli articoli vanno guardati sempre con occhio critico.
La mia invece era una pignoleria su questo
Quote:

Originariamente inviato da aled1974 (Messaggio 46882331)
già con un pattern 64gb in cdm mostra il fianco.... :doh:

(scritto sopra i miei dubbi)
Anzi, @s12a che ne pensi?


Quote:

Originariamente inviato da aled1974 (Messaggio 46882331)
pertanto se si vuole sata+nvme meglio che l'nvme sia quello dell'OS dove risiederanno anche il programma di manipolazione video e le relative librerie/codecs. Questo anche per poter farci altro col pc intanto che elabora il filmato

ma in questo caso (sata+nvme) vuol dire che rientriamo nella categoria degli amatori, con un paio di spicci in più spesi su un solo nvme pensando che così si stravolga l'esperienza di video editing
(per capirci, di quelli che otterrebbero le stesse cose negli stessi tempi con 2 dischi ssd sataIII)



vero ma meglio nvme+sata ;)


Solitamente le librerie non sono dei plugin al software ma texture, effetti, risorse esterne come anche le cache di elaborazione (dipende dal software).
In questo caso meglio un OS e il software su un ssd (anche sata...un nvme sfrutta poco le migliori velocità I/0) e separato l'ssd che viene fatto lavorare più pesantemente durante la produzione.

Si, comunque si parla sempre di uso amatoriale...temo che la workstation degli studi professionali comprenda ancora hdd :D attingendo a piene mani a configurazioni RAID0 :mc:

Andre_Santarell 16-07-2020 13:18

ho fatto un po' di ricerche in giro e sembra di capire che l'ordine è questo:

samsung evo 500gb >> crucial mx 500 500gb >> westernd digital blue 3d 500gb

voi concordate?

il samsung evo mi pare fin troppo costoso, quindi l'indecisione è tra il crucial mx500 e il wd blue 3d..

s12a 16-07-2020 13:40

Quote:

Originariamente inviato da Andre_Santarell (Messaggio 46883121)
[...]
il samsung evo mi pare fin troppo costoso, quindi l'indecisione è tra il crucial mx500 e il wd blue 3d..

Io avrei potuto scegliere fra il Crucial MX500 (che già ho) ed il WD Blue 3D ed alla fine ho preso il secondo perché costava qualche euro di meno e dalle recensioni sembra comportarsi similmente dal punto di vista prestazionale.


Quote:

Originariamente inviato da @Liupen (Messaggio 46883066)
(scritto sopra i miei dubbi)
Anzi, @s12a che ne pensi?

Non mi è chiaro il discorso, non ho seguito la discussione in dettaglio.

Phantom II 17-07-2020 13:09

Quote:

Originariamente inviato da RobbyBtheOriginal (Messaggio 46882344)
Credo di aver capito dagli ultimi interventi, correggetemi se sbaglio, che per il mio utilizzo (descritto qualche post fa) meglio prendere un nvme per s.o. (a questo punto da 512GB immagino) e tenere il bx200 come dati, insieme ai 2HD uno da battaglia e l'altro da 1TB.

Ora per il modello? Vado di sabrent?

In base a quanti si sono espressi sull'argomento e in quali termini, la soluzione che riscuote maggior credito a me pare sia la seguente:
- unità sata per sistema operativo e applicativi;
- unità nvme per i dati

Per quanto riguarda il modello di unità nvme il Sabret mi pare più che adeguato.

makka 17-07-2020 15:29

Per l'utilizzo di RobbyBtheOriginal secondo me è meglio nvme per s.o. e applicativi e il sata per le "cose" che utilizzi di piu' (emulatore), con i dischi meccanici usati come archivio dei dati "statici" e poco utilizzati.
Che emulatori usi per android ? Quanto spazio richiedono ?
Io ho un sata3 da 500Gb e due meccanici, spesso uso delle virtual machine che visto il numero e le dimensioni sono sul disco meccanico da 1Tb.
Quando so che devo usare una vm in modo "pesante" la trasferisco sul sata3 e i miglioramenti sono molto evidenti (ovviamente).
I giochi sono sul disco meccanico ma non li trasferisco mai sul sata3 perchè a parte il caricamento iniziale più veloce non è che ci siano grossi benefici.

RobbyBtheOriginal 17-07-2020 15:31

Ti ringrazio per la risposta, ma per quanto mi riguarda io non ho bisogno di un disco "dedicato" per il videoediting che riguardava quanto discusso poco sopra, ma solo per lo streaming live ed al massimo registrazione di gameplay, solo dopo viene quel poco di videoediting che mi serve sporadicamente.

Sempre se ho capito il discorso:D

edit: come emulatori uso bluestacks ma non portano via praticamente nulla, uso in pratica 2 app, una per emulatore android

s12a 17-07-2020 18:36

Mi è arrivato il Western Digital Blue 3D 500GB prima del previsto. Per il momento l'ho solo montato e non ho neanche inizializzato le partizioni da Windows. Penso comunque di installarci in seguito Linux OpenSUSE Tumbleweed con partizioni in Btrfs.





Ho dovuto usare CrystalDiskInfo perché smartmontools non riconosce correttamente i nomi degli attributi SMART. I valori però sono corretti.
Stranamente (o forse no) viene identificato come SanDisk.


unnilennium 17-07-2020 19:19

Somiglia tanto, pure nella confezione, al Sandisk plus da 500 che ho preso...

Inviato dal mio Nokia 6.1 utilizzando Tapatalk

aled1974 17-07-2020 20:52

Quote:

Originariamente inviato da s12a (Messaggio 46885281)
Mi è arrivato il Western Digital Blue 3D 500GB
...
Stranamente (o forse no) viene identificato come SanDisk.

Quote:

Originariamente inviato da unnilennium (Messaggio 46885321)
Somiglia tanto, pure nella confezione, al Sandisk plus da 500 che ho preso...

Quote:

Originariamente inviato da aled1974 (Messaggio 46882331)
sandisk-wd stesso disco in tutto e per tutto, sandisk in futuro è probabile che non ne vedremo più

^^

:D


Quote:

Originariamente inviato da RobbyBtheOriginal (Messaggio 46885017)
Ti ringrazio per la risposta, ma per quanto mi riguarda io non ho bisogno di un disco "dedicato" per il videoediting che riguardava quanto discusso poco sopra, ma solo per lo streaming live ed al massimo registrazione di gameplay, solo dopo viene quel poco di videoediting che mi serve sporadicamente.

di che bitrate parliamo in entrambi i casi?

perchè potrebbe essere più che sufficiente anche un hdd meccanico :sofico:


ciao ciao

@Liupen 17-07-2020 21:13

Quote:

Originariamente inviato da s12a (Messaggio 46885281)

Ho dovuto usare CrystalDiskInfo perché smartmontools non riconosce correttamente i nomi degli attributi SMART. I valori però sono corretti.
Stranamente (o forse no) viene identificato come SanDisk.


BiCS4 ...TLC 96 Layer (molto aggiornato maggio 2020 ;) )

s12a 17-07-2020 22:00

Prima di installarci OpenSUSE ho effettuato un test con CrystalDiskMark ad impostazioni default. È possibile che le prestazioni in alcuni test siano state limitate dalla CPU (era al massimo dell'occupazione in alcuni frangenti).



Anche il tool WD (praticamente identico a quello SanDisk) lo tratta come un Sandisk:


isomerasi 18-07-2020 02:51



mi sembra sovrapponibile al mio evo 500 di 5 anni fa...sbaglio o non si sono fatti passi avanti per i sata 3 (a parte che allora lo pagai euro 185,16) ?

Quote:

Originariamente inviato da s12a (Messaggio 46885479)
Prima di installarci OpenSUSE ho effettuato un test con CrystalDiskMark ad impostazioni default. È possibile che le prestazioni in alcuni test siano state limitate dalla CPU (era al massimo dell'occupazione in alcuni frangenti).



Anche il tool WD (praticamente identico a quello SanDisk) lo tratta come un Sandisk:



aled1974 18-07-2020 07:35

Quote:

Originariamente inviato da isomerasi (Messaggio 46885572)
mi sembra sovrapponibile al mio evo 500 di 5 anni fa...sbaglio o non si sono fatti passi avanti per i sata 3 (a parte che allora lo pagai euro 185,16) ?

i limiti del protocollo sataIII sono quelli, non ci saranno nand o controller che li possano superare e non so se vedremo un eventuale sata3.3 o 4.0 :boh:

se si vuole o si necessita di maggiore velocità c'è il protocollo nvme, arrivato per ora al gen4 x4 (salvo gabole per raggiungere il x16)
del resto è il futuro e lo si vede anche dai prodotti "farlocchi", ovvero di qualità medio-bassa, che stanno uscendo popolando il mercato e vendendo a pacchi a chi non si accorgerà mai dei loro limiti perchè utilizzati in ambito desktop (quindi niente workload pesanti) ;)

di passi avanti (in realtà io li considero passi indietro) sugli ssd sataIII ne sono stati fatti con la tecnologia multilayer delle nuove nand, siamo passati da TLC a QLC, con i prodotti PLC già in fase avanzatissima :)
es. https://www.pcgamesn.com/toshiba-plc...tlc-qlc-drives

ciao ciao


Edit
tornando al disco di s12a, dimenticavo in effetti che non è proprio un disco sandisk visto che di fatto le nand sono toshiba, diciamo che wd vende ssd sandisk rimarchiandoli (più o meno, e ricordando che sandisk è proprietà wd) ma che poi utilizza nand toshiba (ora kioxia, ex ocz) :sofico: :asd:

Phantom II 18-07-2020 11:41

Quote:

Originariamente inviato da s12a (Messaggio 46885281)
Penso comunque di installarci in seguito Linux OpenSUSE Tumbleweed con partizioni in Btrfs.

C'è un motivo particolare per cui sceglierai come file system Btrfs al posto di Ext4?

s12a 18-07-2020 13:11

Snapshot, compressione, online resizing, ma principalmente il fatto che non ho ancora avuto l'opportunità di usarlo a lungo come filesystem principale. Visto che ultimamente l'installer di OpenSUSE lo propone come scelta di defaulta anche per la /home, mi sembrava l'occasione giusta per provare.

Tuttavia dopo diversi test (e qualche centinaio di GB scritti) ed aver cambiato diverse impostazioni non sono riuscito a fare andare in scrittura l'SSD a più di 250-300 MB/s reali, indipendentemente dal tipo di carico. In lettura arriva a 550 MB/s. Questo senza tenere conto della compressione zstd che ho abilitato.

Ecco un esempio provando a trasferire dal file manager di KDE Plasma5 un file .iso da 4 GB dal Crucial MX500 (NTFS) al WD Blue 3D (BtrFS):


giovanni69 18-07-2020 14:08

Ecco questo è uno dei tuoi test sempre interessanti per un motivo o per un altro :)

@Liupen 18-07-2020 14:20

Quote:

Originariamente inviato da s12a (Messaggio 46885479)
Prima di installarci OpenSUSE ho effettuato un test con CrystalDiskMark ad impostazioni default. È possibile che le prestazioni in alcuni test siano state limitate dalla CPU (era al massimo dell'occupazione in alcuni frangenti).

La nuova versione di crystaldiskmark (7) a differenza della precedente, fa lavorare tutti i core, quindi dovrebbe essere favorevole al multicore e meno limitante sulle macchine meno performanti.
Potresti però aver notato un aumento degli rpm delle ventole, visto che tutti i core in quel momento sono stati caricati.
[Il parametro corrisponde a "affinità predefinita" = disable]


Quote:

Originariamente inviato da aled1974 (Messaggio 46885626)
tornando al disco di s12a, dimenticavo in effetti che non è proprio un disco sandisk visto che di fatto le nand sono toshiba, diciamo che wd vende ssd sandisk rimarchiandoli (più o meno, e ricordando che sandisk è proprietà wd) ma che poi utilizza nand toshiba (ora kioxia, ex ocz) :sofico: :asd:

Mi sa che ormai è meglio dire che i Sandisk sono rimarchiati WD, il know-out di Sandisk è finito... RIP.
Ora WD e Toshiba sono partner e la produzione/qualità si allinea. In particolare, a inizio anno, la produzione di NAND TLC/QLC di Samsung è stata superata dalla produzione di FAB6 Toshiba/WD.
Questo WD Blue 3D è l'eccezione che conferma la regola; un ssd con vecchio controller Marvell e algoritmi studiati dai "vecchi" ingegneri e con nuove celle.
Il controller è un duro: 4 canali/8CE con controllo errori avanzato.
EDIT. ecco rileggendo mi è venuto in mente che proprio l'utilizzo di celle nuove, quindi pacchetti più densi, potrebbe aver tolto parallelismo, a questo controller che è capace di attingere bene da più pacchetti NAND, quindi calando le prestazioni sotto richieste multiple (roba che non si nota nei bench, come sempre). Ipotesi eh...

Quote:

Originariamente inviato da s12a (Messaggio 46886026)
Tuttavia dopo diversi test (e qualche centinaio di GB scritti) ed aver cambiato diverse impostazioni non sono riuscito a fare andare in scrittura l'SSD a più di 250-300 MB/s reali, indipendentemente dal tipo di carico. In lettura arriva a 550 MB/s. Questo senza tenere conto della compressione zstd che ho abilitato.

Anche rientrando nella capacità di cache? Crea un .iso da 250 MB, prova... :muro:

vw1961 18-07-2020 14:58

scusate ma CrystalMark per testare le chiavette USB , meglio settare su 500mb o 1Gi ?

s12a 18-07-2020 16:15

Quote:

Originariamente inviato da @Liupen (Messaggio 46886093)
Anche rientrando nella capacità di cache? Crea un .iso da 250 MB, prova... :muro:

Ho effettuato diverse prove. Ero convinto fosse un problema software (btrfs non è un file system progettato per essere particolarmente prestazionale), ma alla fine ho provato a creare una piccola partizione NTFS da 12GB sempre sullo stesso SSD ed effettuare gli stessi test da Linux.

Ho notato che un breve test di scrittura sequenziale con il benchmark fio su un file da 4 GB inizialmente va a 550-570 MB/s come ci si aspetterebbe. Tuttavia ripetendo i test la velocità cala sempre più, scendendo fino a circa 220-250 MB/s instabili.

Eliminare il file di test creato dall'operazione, forzare un trim (sudo fstrim -v ./) e ripetere l'operazione ripristina le prestazioni in scrittura iniziali, ma queste calano dopo un po' attorno al livello precedentemente osservato.

Non so se sia una caratteristica od un bug del sistema operativo (rolling release) correlati a come funziona il trim su Linux, oppure dell'SSD. Il filesystem non sembra essere il punto critico. Potrebbe essere una combinazione di entrambe le cose dato che non ho notato simili cali con Windows usando CrystalDiskMark e 10x4 GB test in sequenziale consecutivi, usando la stessa partizione.

s12a 18-07-2020 18:08

Credo di avere trovato il problema. Non è né Linux né Btrfs (od almeno non direttamente, in larga parte). Sembra che il Western Digital Blue 3D sia particolarmente sensibile all'assenza del trim. Disabilitandolo e "sporcando" l'SSD, anche su Windows la velocità in scrittura dopo un po' tende a calare a livello di quanto avevo osservato su Linux. Questo si nota più nei trasferimenti sequenziali di file di grossa dimensione (da un SSD all'altro) che con CrystalDiskMark.

Questo è quello che succede transferendo un file iso di qualche GB da un SSD all'altro. L'occupazione dell'SSD di destinazione (Western Digital Blue 3D) va al 100% e la velocità dopo un picco iniziale cala fino a circa 200 MB/s:

(notare che per qualche motivo l'SSD è riconosciuto come Samsung 830, ma non ne ho uno installato al momento)


Per disabilitare il trim su Windows, da prompt dei commandi o Powershell con permessi di Amministratore:

Codice PHP:

fsutil behavior set disabledeletenotify 1 


giovanni69 18-07-2020 20:48

:ave:

Trotto@81 18-07-2020 21:31

Quote:

Originariamente inviato da s12a (Messaggio 46886325)
Credo di avere trovato il problema. Non è né Linux né Btrfs (od almeno non direttamente, in larga parte). Sembra che il Western Digital Blue 3D sia particolarmente sensibile all'assenza del trim. Disabilitandolo e "sporcando" l'SSD, anche su Windows la velocità in scrittura dopo un po' tende a calare a livello di quanto avevo osservato su Linux. Questo si nota più nei trasferimenti sequenziali di file di grossa dimensione (da un SSD all'altro) che con CrystalDiskMark.

Questo è quello che succede transferendo un file iso di qualche GB da un SSD all'altro. L'occupazione dell'SSD di destinazione (Western Digital Blue 3D) va al 100% e la velocità dopo un picco iniziale cala fino a circa 200 MB/s:

(notare che per qualche motivo l'SSD è riconosciuto come Samsung 830, ma non ne ho uno installato al momento)

Per disabilitare il trim su Windows, da prompt dei commandi o Powershell con permessi di Amministratore:

Codice PHP:

fsutil behavior set disabledeletenotify 1 


Perché hai disabilitato il TRIM?

s12a 18-07-2020 21:47

Quote:

Originariamente inviato da Trotto@81 (Messaggio 46886508)
Perché hai disabilitato il TRIM?

Per verificare che fosse effettivamente la causa del problema. Generalmente su Linux il trim in tempo reale (flag discard nelle opzioni di mount delle partizioni) non è abilitato di default, ed anche abilitandolo non funziona allo stesso modo di quello di Windows.

Inoltre il filesystem Btrfs (su Linux) è di tipo copy-on-write (https://it.wikipedia.org/wiki/Copy-on-write), e questo credo che generi un maggiore numero di settori logici "sporcati" da scritture. Quindi lo spazio libero trimmato sarà di conseguenza in media inferiore e le prestazioni in scrittura tenderanno a degradare più velocemente (o peggio essere praticamente sempre in uno stato degradato).

Dopo aver verificato l'origine del problema, ho riabilitato il trim su Windows. Nelle ultime 2 ore ho clonato il sistema Windows sul Western Digital Blue 3D e reinstallato OpenSUSE sul Crucial MX500. Non ho effettuato ancora prove prolungate, ma credo che il Crucial si comporti meglio in tali condizioni d'uso e che il Western Digital sia più indicato per Windows. In generale comunque forse sarebbe stato meglio prendere un altro Crucial MX500 oppure qualcos'altro di fascia equivalente o superiore.

aled1974 19-07-2020 07:45

Quote:

Originariamente inviato da aled1974 (Messaggio 46885626)
tornando al disco di s12a, dimenticavo in effetti che non è proprio un disco sandisk visto che di fatto le nand sono toshiba, diciamo che wd vende ssd sandisk rimarchiandoli (più o meno, e ricordando che sandisk è proprietà wd) ma che poi utilizza nand toshiba (ora kioxia, ex ocz) :sofico: :asd:

Quote:

Originariamente inviato da @Liupen (Messaggio 46886093)
Mi sa che ormai è meglio dire che i Sandisk sono rimarchiati WD,

^^ dove sta la differenza concettuale? :mbe:

sandisk non esiste più, non hanno neanche più i loro spazi web, wd ne ha fatto piazza pulita

Quote:

il know-out di Sandisk è finito... RIP.
è il know-out di WD che latita in campo ssd, al punto che dall'oggi al domani si sono resi conto di essere anacronisticamente tagliati fuori dal mercato più attivo in ambito dischi e per cercare di rimediare in fretta han pappato la prima società che potevano papparsi.... sandisk e il suo know-out sugli ssd

perchè è sandisk quella che per anni ha studiato e investito su prodotti nand-based

se wd avesse dovuto partire da zero con R&D sugli ssd il loro primo disco sarebbe ancora da venire, ed è così' visto che tuttora sta vendendo prodotti sandisk rimarchiandoli

anzi, a voler essere cattivi... non riescono neanche a cambiare i template della loro stessa utility in modo che appaia scritto WD invece di Sandisk

Quote:

Ora WD e Toshiba sono partner e la produzione/qualità si allinea. In particolare, a inizio anno, la produzione di NAND TLC/QLC di Samsung è stata superata dalla produzione di FAB6 Toshiba/WD.
le bics toshiba costano meno, vengono prodotte in quantità e le usano un po' tutti (wd, silicon power, sabrent, ecc.) :mano:

di fatto il mercato è invaso da prodotti clone, con minime variazioni sul controller adottato dai vari marchi e con prestazioni necessariamente simili

Quote:

Questo WD Blue 3D è l'eccezione che conferma la regola; un ssd con vecchio controller Marvell e algoritmi studiati dai "vecchi" ingegneri e con nuove celle.
Il controller è un duro: 4 canali/8CE con controllo errori avanzato.
aspettiamo i prodotti dei "nuovi ingegneri" allora, ma non so se wd sarà in grado entro breve di produrre un controller migliore di quello (phison?) adottato da kioxia/toshiba per le nand toshiba con le prestazioni "senza compromessi" degli exceria plus :boh:

Quote:

EDIT. ecco rileggendo mi è venuto in mente che proprio l'utilizzo di celle nuove, quindi pacchetti più densi, potrebbe aver tolto parallelismo, a questo controller che è capace di attingere bene da più pacchetti NAND, quindi calando le prestazioni sotto richieste multiple (roba che non si nota nei bench, come sempre). Ipotesi eh...
niente di più facile :mano:

ma non so se mai qualcuno oggi si prenderà la briga di approfondire l'aspetto fino a questo punto per un prodotto sataIII mid level, visto che tutti (produttori, consumatori, recensori) sono nvme-oriented "de brutto" :sofico:

ciao ciao


EDIT
per chi se l'è perso o se l'è scordato, qualora aveste w10 2004 (may update) ricordatevi di disabilitare la funzionalità trim/defrag :read:

@Liupen 19-07-2020 11:14

Quote:

Originariamente inviato da s12a (Messaggio 46886225)
Ho effettuato diverse prove. Ero convinto fosse un problema software (btrfs non è un file system progettato per essere particolarmente prestazionale), ma alla fine ho provato a creare una piccola partizione NTFS da 12GB sempre sullo stesso SSD ed effettuare gli stessi test da Linux.

Ho notato che un breve test di scrittura sequenziale con il benchmark fio su un file da 4 GB inizialmente va a 550-570 MB/s come ci si aspetterebbe. Tuttavia ripetendo i test la velocità cala sempre più, scendendo fino a circa 220-250 MB/s instabili.

Eliminare il file di test creato dall'operazione, forzare un trim (sudo fstrim -v ./) e ripetere l'operazione ripristina le prestazioni in scrittura iniziali, ma queste calano dopo un po' attorno al livello precedentemente osservato.

Non so se sia una caratteristica od un bug del sistema operativo (rolling release) correlati a come funziona il trim su Linux, oppure dell'SSD. Il filesystem non sembra essere il punto critico. Potrebbe essere una combinazione di entrambe le cose dato che non ho notato simili cali con Windows usando CrystalDiskMark e 10x4 GB test in sequenziale consecutivi, usando la stessa partizione.

Quote:

Originariamente inviato da s12a (Messaggio 46886325)
Credo di avere trovato il problema. Non è né Linux né Btrfs (od almeno non direttamente, in larga parte). Sembra che il Western Digital Blue 3D sia particolarmente sensibile all'assenza del trim. Disabilitandolo e "sporcando" l'SSD, anche su Windows la velocità in scrittura dopo un po' tende a calare a livello di quanto avevo osservato su Linux. Questo si nota più nei trasferimenti sequenziali di file di grossa dimensione (da un SSD all'altro) che con CrystalDiskMark.

Questo è quello che succede transferendo un file iso di qualche GB da un SSD all'altro. L'occupazione dell'SSD di destinazione (Western Digital Blue 3D) va al 100% e la velocità dopo un picco iniziale cala fino a circa 200 MB/s:

(notare che per qualche motivo l'SSD è riconosciuto come Samsung 830, ma non ne ho uno installato al momento)


Per disabilitare il trim su Windows, da prompt dei commandi o Powershell con permessi di Amministratore:

Codice PHP:

fsutil behavior set disabledeletenotify 1 


Quote:

Originariamente inviato da s12a (Messaggio 46886517)
Per verificare che fosse effettivamente la causa del problema. Generalmente su Linux il trim in tempo reale (flag discard nelle opzioni di mount delle partizioni) non è abilitato di default, ed anche abilitandolo non funziona allo stesso modo di quello di Windows.

Inoltre il filesystem Btrfs (su Linux) è di tipo copy-on-write (https://it.wikipedia.org/wiki/Copy-on-write), e questo credo che generi un maggiore numero di settori logici "sporcati" da scritture. Quindi lo spazio libero trimmato sarà di conseguenza in media inferiore e le prestazioni in scrittura tenderanno a degradare più velocemente (o peggio essere praticamente sempre in uno stato degradato).

Dopo aver verificato l'origine del problema, ho riabilitato il trim su Windows. Nelle ultime 2 ore ho clonato il sistema Windows sul Western Digital Blue 3D e reinstallato OpenSUSE sul Crucial MX500. Non ho effettuato ancora prove prolungate, ma credo che il Crucial si comporti meglio in tali condizioni d'uso e che il Western Digital sia più indicato per Windows. In generale comunque forse sarebbe stato meglio prendere un altro Crucial MX500 oppure qualcos'altro di fascia equivalente o superiore.


Nella copia reale è un comportamento normale, su file .iso (comunque compressi) quello di max prestazioni a cache di scrittura vuota e un calo improvviso se la scrittura dura di più (t) al di là della mole di dati da scrivere. In realtà avresti trovato il limite della scrittura su celle TLC 96L di quel prodotto, proprio come ad esempio un Sabrent Rocket nvme (nand Micron TLC 96L) quando esaurisce la cache di scrittura, scende immancabilmente sui 1200 MB/s.

Crystaldiskmark lascia perdere, si ottengono solo valori di massime prestazioni (occorrerebbe variare veramente la dimensione del file di bench portandolo da 1MiB a qualcosa di superiore (già detto che la grandezza del file di test 1GiB--> 64GiB, non è la dimensione del file letto o scritto durante il bench).

Il calo di prestazioni con il TRIM disabilitato questo si che è un dato. La chiamata TRIM può darsi che sia predisposta dal controller Marvell molto più assiduamente, tanto da influire sulle prestazioni in tempo reale? Questo vuol dire però che il tuo Blue è oltre il primo ciclo? (Cappero lo stai martellando :D ).

Noto un tono di delusione nell'acquisto di questo WD Blue 3D...pensare che per le review UK è un modello ancora molto valido.

Riguardo il mancato/sbagliato riconoscimento dell'ssd da parte di Windows... mi sono accorto ora di avere anch'io il medesimo problema. Windows attualmente mi dice che il mio OS è su un Samsung 850 evo mentre so benissimo che è sul Samsung 840 PRO... fortuna che Crystaldiskinfo conferma.
Per chi ha più di un ssd e ssd diversi sulla medesima macchina, vorrei chiedere se anche voi avete questo problema...che non è da poco visto che il riconoscimento di un device ne determina la gestione con potenziali gravi problemi.
Grazie a chi vorrà perderci qualche minuto.




Quote:

Originariamente inviato da aled1974 (Messaggio 46886681)
^^ dove sta la differenza concettuale? :mbe:

sandisk non esiste più, non hanno neanche più i loro spazi web, wd ne ha fatto piazza pulita



è il know-out di WD che latita in campo ssd, al punto che dall'oggi al domani si sono resi conto di essere anacronisticamente tagliati fuori dal mercato più attivo in ambito dischi e per cercare di rimediare in fretta han pappato la prima società che potevano papparsi.... sandisk e il suo know-out sugli ssd

perchè è sandisk quella che per anni ha studiato e investito su prodotti nand-based

se wd avesse dovuto partire da zero con R&D sugli ssd il loro primo disco sarebbe ancora da venire, ed è così' visto che tuttora sta vendendo prodotti sandisk rimarchiandoli

anzi, a voler essere cattivi... non riescono neanche a cambiare i template della loro stessa utility in modo che appaia scritto WD invece di Sandisk

le bics toshiba costano meno, vengono prodotte in quantità e le usano un po' tutti (wd, silicon power, sabrent, ecc.) :mano:

di fatto il mercato è invaso da prodotti clone, con minime variazioni sul controller adottato dai vari marchi e con prestazioni necessariamente simili

aspettiamo i prodotti dei "nuovi ingegneri" allora, ma non so se wd sarà in grado entro breve di produrre un controller migliore di quello (phison?) adottato da kioxia/toshiba per le nand toshiba con le prestazioni "senza compromessi" degli exceria plus :boh:

niente di più facile :mano:

ma non so se mai qualcuno oggi si prenderà la briga di approfondire l'aspetto fino a questo punto per un prodotto sataIII mid level, visto che tutti (produttori, consumatori, recensori) sono nvme-oriented "de brutto" :sofico:

ciao ciao

EDIT
per chi se l'è perso o se l'è scordato, qualora aveste w10 2004 (may update) ricordatevi di disabilitare la funzionalità trim/defrag :read:

Aled intendevo proprio che ormai gli ssd Sandisk non esistono più ma sono dei veri e propri WD marchiati Sandisk (e non si sà perchè infangare ciò che di buono c'era nel nome Sandisk!).
Il fatto che il file .inf sia confuso oppure che il firmware di WD Blue e Sandisk Ultra (il modello gemello) sia uguale e che un il WD appaia come Sandisk, secondo me la dice solo lunga sul fatto che una volta di più WD ha affossato Sandisk (è uno sfogo, scusate).
Vero che Sandisk ha fornito la tecnologia di assemblaggio degli SSD a WD con i rapporti commerciali di Intel/Micron e Toshiba. Ma quei tempi sono finiti.
In 2 anni la tecnologia (e i rapporti commerciali) sono cambiati.
Dal 2018 WD è finanziatore e utilizzatore della produzione nand Giapponese ed ha ovviamente accesso ai controller Toshiba (che più di due anni fà erano prodotti da altri, ma ora sembra di no).
Riguardo la qualità Toshiba..pardon Kioxia :Prrr: non mi stupirebbe trovarli in cima alla classifica. Ho visto un azienda in forte crisi finanziaria (speculativa) nel comparto storage, tirarsi su con hdd veloci ed economici e moltiplicando gli investimenti nel settore memorie flash.. Exceria Plus è da rivalutare, se il prezzo sarà competitivo (opinione personale).

Phantom II 19-07-2020 11:29

Quote:

Originariamente inviato da s12a (Messaggio 46886026)
Snapshot, compressione, online resizing, ma principalmente il fatto che non ho ancora avuto l'opportunità di usarlo a lungo come filesystem principale. Visto che ultimamente l'installer di OpenSUSE lo propone come scelta di defaulta anche per la /home, mi sembrava l'occasione giusta per provare.

Grazie per il chiarimento e in genere per ciò che dettagli nei tuoi messaggi.
Visto che siamo in tema, a tuo parere qual è il modo migliore di impostare il trim su sistemi Linux?

Phantom II 19-07-2020 11:34

Quote:

Originariamente inviato da aled1974 (Messaggio 46886681)
è il know-out di WD che latita in campo ssd, al punto che dall'oggi al domani si sono resi conto di essere anacronisticamente tagliati fuori dal mercato più attivo in ambito dischi e per cercare di rimediare in fretta han pappato la prima società che potevano papparsi.... sandisk e il suo know-out sugli ssd

È la dinamica economica che lo impone, e infatti ha riguardato ogni settore industriale. Quello informatico non fa eccezione, lo si verifica empiricamente dando una scorsa al mare di fusioni/acquisizioni che si sono verificate negli ultimi 20 anni.

s12a 19-07-2020 11:50

Quote:

Originariamente inviato da @Liupen (Messaggio 46886935)
Nella copia reale è un comportamento normale, su file .iso (comunque compressi) quello di max prestazioni a cache di scrittura vuota e un calo improvviso se la scrittura dura di più (t) al di là della mole di dati da scrivere. In realtà avresti trovato il limite della scrittura su celle TLC 96L di quel prodotto, proprio come ad esempio un Sabrent Rocket nvme (nand Micron TLC 96L) quando esaurisce la cache di scrittura, scende immancabilmente sui 1200 MB/s.

Ho provato lo stesso file iso dal WD Blue3D (NTFS) al Crucial MX500 (Btrfs, Linux) e non ho questi problemi e tocca 500 MB/s come ci si aspetterebbe, anche se non fissi. Anche ripetere l'operazione più volte consecutivamente non provoca cali a 200 MB/s circa.



Quote:

Crystaldiskmark lascia perdere, si ottengono solo valori di massime prestazioni (occorrerebbe variare veramente la dimensione del file di bench portandolo da 1MiB a qualcosa di superiore (già detto che la grandezza del file di test 1GiB--> 64GiB, non è la dimensione del file letto o scritto durante il bench).
Ho usato anche un benchmark chiamato "fio", alquanto impostabile. C'è anche per Windows.

https://github.com/axboe/fio

Quote:

Il calo di prestazioni con il TRIM disabilitato questo si che è un dato. La chiamata TRIM può darsi che sia predisposta dal controller Marvell molto più assiduamente, tanto da influire sulle prestazioni in tempo reale? Questo vuol dire però che il tuo Blue è oltre il primo ciclo? (Cappero lo stai martellando :D ).
Sì, probabilmente ho effettuato fin troppe scritture, ma ora non ne ho altre da fare di questo tipo. È al secondo ciclo ed il numero massimo di cicli riportato è 3.

Quote:

Noto un tono di delusione nell'acquisto di questo WD Blue 3D...pensare che per le review UK è un modello ancora molto valido.
Il Crucial MX500 mi sembra in generale migliore a tutto tondo per il momento. È possibile però che abbia stressato il WDBlue 3D troppo in poco tempo, e che le altre condizioni non ottimali abbiano fatto il resto.

Per contro il Blue 3D sembra sopportare meglio l'apertura di molti programmi insieme l'avvio del PC (da Windows) rispetto all'MX500.


Quote:

Originariamente inviato da Phantom II (Messaggio 46886955)
Grazie per il chiarimento e in genere per ciò che dettagli nei tuoi messaggi.
Visto che siamo in tema, a tuo parere qual è il modo migliore di impostare il trim su sistemi Linux?

Di solito si tende a consigliare di effettuare manualmente una passata di trim con fstrim. Secondo me non è una soluzione ottimale ed effettuarlo ogni tot giorni può non bastare in caso di notevoli quantità di scritture effettuate in poco tempo.

Al momento io ho semplicemente abilitato il flag "discard" per la partizione Btrfs in fstab, che sembra funzionare bene sul Crucial MX500, ma che avevo l'impressione che sotto stress desse problemi con il WD Blue 3D, causando impuntamenti vari.

C'è anche un "discard=async" impostabile con Btrfs. Questo sembrava andare bene con il Blue 3D.
https://wiki.archlinux.org/index.php/Btrfs#SSD_TRIM

Al momento per / con MX500 ho impostato in fstab "defaults,noatime,compress-force=zstd:2,discard"

Andre_Santarell 19-07-2020 11:56

non ho capito perché vuoi disabilitare il trim, se con il trim funziona meglio.

Andre_Santarell 19-07-2020 12:01

domanda: meglio secondo voi:
- il wd ssd blue 3d 500gb nuovo a 58 euro spedito su amazon
- un samsung evo 840 500gb usato senza garanzia (ma cmq perfettamente funzionante) a 53 spedito?
- un samsung evo 850 500gb usato senza garanzia (ma cmq perfettamente funzionante) a 58 spedito?

s12a 19-07-2020 12:03

Quote:

Originariamente inviato da Andre_Santarell (Messaggio 46887004)
non ho capito perché vuoi disabilitare il trim, se con il trim funziona meglio.

Come scritto in precedenza:

Quote:

Originariamente inviato da s12a (Messaggio 46886517)
Per verificare che fosse effettivamente la causa del problema. Generalmente su Linux il trim in tempo reale (flag discard nelle opzioni di mount delle partizioni) non è abilitato di default, ed anche abilitandolo non funziona allo stesso modo di quello di Windows.

[...]

Dopo aver verificato l'origine del problema, ho riabilitato il trim su Windows.


Phantom II 19-07-2020 18:13

Quote:

Originariamente inviato da s12a (Messaggio 46886996)
Di solito si tende a consigliare di effettuare manualmente una passata di trim con fstrim. Secondo me non è una soluzione ottimale ed effettuarlo ogni tot giorni può non bastare in caso di notevoli quantità di scritture effettuate in poco tempo.

Al momento io ho semplicemente abilitato il flag "discard" per la partizione Btrfs in fstab, che sembra funzionare bene sul Crucial MX500, ma che avevo l'impressione che sotto stress desse problemi con il WD Blue 3D, causando impuntamenti vari.

C'è anche un "discard=async" impostabile con Btrfs. Questo sembrava andare bene con il Blue 3D.
https://wiki.archlinux.org/index.php/Btrfs#SSD_TRIM

Al momento per / con MX500 ho impostato in fstab "defaults,noatime,compress-force=zstd:2,discard"

Ti ringrazio per la spiegazione.
Devo fare mente locale per ricostruire cosa avessi impostato su Ubuntu 18.04 ai tempi dell'installazione, è anche probabile che abbia lasciato tutto a default.
Ricordo che per le precedenti distribuzioni si diceva che la gestione automatica del sistema funzionava meglio su drive Samsung, rispetto ad altri.

s12a 19-07-2020 19:24

Non credo che nessuna distribuzione abiliti ancora discard di default come opzione di mount. Da quello che ricordo Ubuntu usava un cron job settimanale per effettuare il trim dello spazio libero periodicamente con fstrim perché alcuni SSD avevano problemi anche seri con discard; non so se sia ancora il caso. Una volta a settimana secondo me è troppo poco in assenza di trim in real-time comunque, a meno di fare usi molto leggeri del pc.


Tutti gli orari sono GMT +1. Ora sono le: 22:41.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Hardware Upgrade S.r.l.