SanDisk SSD Plus: metà delle prestazioni su Linux che su Windows?

Ho due SSD nel mio laptop:

  • Crucial MX300 725GB -> / dev / sda
  • SanDisk SSD Plus 240 GB -> / dev / sdb

Le loro prestazioni si leggono su Linux e Windows in questo modo:

Crucial MX300 -> uguale su entrambi i sistemi operativi

sudo hdparm -tT /dev/sda # Crucial Timing cached reads: 13700 MB in 2.00 seconds = 6854.30 MB/sec Timing buffered disk reads: 1440 MB in 3.00 seconds = 479.58 MB/sec 

Crucial MX300 725GB

SanDisk Plus -> molto più veloce su Windows!

 sudo hdparm -tT /dev/sdb # SanDisk Timing cached reads: 7668 MB in 2.00 seconds = 3834.92 MB/sec Timing buffered disk reads: 798 MB in 3.00 seconds = 265.78 MB/sec # TOO LOW !! 

SanDisk

Le prestazioni di lettura sequenziale di SanDisk su Linux sono circa la metà delle sue prestazioni su Windows!

La mia domanda è ovviamente: perché e può essere risolto? Ciò è dovuto al fatto che il SanDisk SSD Plus viene gestito come un’unità SCSI ?

Da syslog:

 ~$ grep SDSSD /var/log/syslog systemd[1]: Found device SanDisk_SDSSDA240G kernel: [ 2.152138] ata2.00: ATA-9: SanDisk SDSSDA240G, Z32070RL, max UDMA/133 kernel: [ 2.174689] scsi 1:0:0:0: Direct-Access ATA SanDisk SDSSDA24 70RL PQ: 0 ANSI: 5 smartd[1035]: Device: /dev/sdb [SAT], SanDisk SDSSDA240G, S/N:162783441004, WWN:5-001b44-4a404e4f0, FW:Z32070RL, 240 GB smartd[1035]: Device: /dev/sdb [SAT], state read from /var/lib/smartmontools/smartd.SanDisk_SDSSDA240G-162783441004.ata.state smartd[1035]: Device: /dev/sdb [SAT], state written to /var/lib/smartmontools/smartd.SanDisk_SDSSDA240G-162783441004.ata.state 

Rispetto al Crucial MX300 che ha su Linux quasi le stesse prestazioni di Windows:

 ~$ grep MX300 /var/log/syslog systemd[1]: Found device Crucial_CT750MX300SSD1 kernel: [ 1.775520] ata1.00: ATA-10: Crucial_CT750MX300SSD1, M0CR050, max UDMA/133 smartd[1035]: Device: /dev/sda [SAT], Crucial_CT750MX300SSD1, S/N:16251486AC40, WWN:5-00a075-11486ac40, FW:M0CR050, 750 GB smartd[1035]: Device: /dev/sda [SAT], state read from /var/lib/smartmontools/smartd.Crucial_CT750MX300SSD1-16251486AC40.ata.state smartd[1035]: Device: /dev/sda [SAT], state written to /var/lib/smartmontools/smartd.Crucial_CT750MX300SSD1-16251486AC40.ata.state 

Qualsiasi aiuto è molto gradito!

Modificare:

La differenza che hdparm sta mostrando su Linux è molto reale. Ho creato due directory identiche, una in ciascuna delle due unità, ciascuna directory contenente circa 25 GB di file (36395 file) e ha eseguito lo stesso identico script di creazione di checksum hashdeep su entrambe le directory (lo script crea semplicemente un checksum md5 per ogni file nel test dirs e memorizza tutti i checksum in un singolo file). Questi sono i risultati:

 test-sandisk# time create-file-integrity-md5sums.sh . real 1m49.000s user 1m24.868s sys 0m15.808s test-mx300# time create-file-integrity-md5sums.sh . real 0m54.180s user 1m4.628s sys 0m11.640s 

Stesso test con un singolo file 7Gb:

 test-sandisk# time create-file-integrity-md5sums.sh . real 0m26.986s user 0m19.168s sys 0m3.232s test-mx300# time create-file-integrity-md5sums.sh . real 0m17.285s user 0m16.248s sys 0m1.368s 

Modifica 2:

Le partizioni sono allineate “ottimali” e l’unica differenza in / sys / block / $ disk / queue è discard_zeroes_data (1 su Crucial, 0 su SanDisk). File system e opzioni di assembly utilizzate: tipo ext4 (rw, nosuid, nodev, relatime, data = ordered, uhelper = udisks2)

 dmesg | grep -i sata | grep 'link up' [ 1.936764] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 2.304548] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) 

Questa potrebbe non essere una risposta abbastanza buona, ma io sono nuovo e non posso “commentare”, e volevo condividere con te nel caso in cui aiuti:

Lavoravo con memorie flash eMMC, basi hardware simili come SSD. discard_zeroes_data suona come potrebbe avere importanza. C’erano caratteristiche molto lente chiamate Erase e soprattutto Trim (come Erase, ma su una base di blocco di 4kB invece del molto più grande Erase Group Block necessario per le prestazioni. In seguito è stata introdotta una funzione “Discard” che non ha cancellato i dati tutti zeri (veramente tutti sotto il cofano, ma invertiti per comodità), ma hanno appena cambiato lo stato dei dati in “non importa”.

Quindi, se hai fatto uno scarto su 4kB di dati, è stato più veloce perché non ha fatto una cancellazione, ma lascia che il firmware sappia che non hai più bisogno dei dati e ha tenuto traccia di quell’area fisica in una tabella. Ciò ha consentito al tipo di meccanismo di raccolta dei rifiuti di recuperare tale posizione dei dati (probabilmente re-mappandoli a un indirizzo diverso) in seguito, quando è ansible cancellare un numero sufficiente di suoi vicini, copiando i dati necessari in un’altra area secondo necessità e quindi eseguendo il costoso “Cancella” “operazione in background.

TBH abbiamo finito per disabilitare la discard in un primo momento, perché non funzionava così bene e ci ha causato problemi di prestazioni quando sono stati lasciati troppi dati nello stato di scarto, e le cancellazioni fisiche non sono mai avvenute.

Quindi non posso dire cosa significhi “discard_zeros_data”, ma se fossi in te sicuramente proverei a cambiarlo allo stato opposto e vedere cosa succede. Se si legge come “object object sobject”, allora potrebbe essere una funzione di sicurezza in cui ci vuole tempo per cancellare forzatamente anche piccoli bit di dati (costosi) in modo che non ci siano possibilità che qualcuno possa recuperare i vecchi file dopo aver pensato che tu sia ” li ho cancellati. Penserei che impostare questo a “Zero” aumenterebbe effettivamente le prestazioni, se è così che lo leggi, ma stai vedendo il contrario.

Prova anche a eseguire la più grande “cancellazione” forzata che sei in grado, sia che usi speciali strumenti SSD, o un formato completo, o qualcosa del genere, e vedere se le prestazioni sono migliori subito dopo questa cancellazione. Questo ti darà almeno alcune informazioni sul problema.

Anche il tipo di filesystem dovrebbe essere importante, ma penso che sia una costante nei tuoi due esperimenti.

Confronto con chiavette USB

Le semplici pendrive USB diventano più lente gradualmente dopo essere state utilizzate per un po ‘. Tali dischi non hanno funzionalità di scarto (per quanto ne so, non parlo di pendrive avanzate e molto costose). Pulendo tutte le unità, sovrascrivendo con zero (o internamente) si ripristinerà nuovamente la velocità. Dalla mia esperienza personale so che questo si applica alle pendrive Sandisk Extreme, che sono veloci quando nuove (rispetto alle altre semplici pendrive USB).

Quindi posso aspettarmi che il metodo degli scarti (o la mancanza di esso) possa essere responsabile della riduzione delle prestazioni anche nel Sandisk SSD. Penso che la risposta di @ Starman aggiunga informazioni preziose per risolvere il tuo problema.

Puoi

  • prova a lasciare inattivo il sistema durante la notte e controlla se ha utilizzato il tempo di inattività per recuperare quello che dovrebbe essere scartato. Se non hai fortuna, puoi

  • pulire lo spazio libero dell’unità e controllare se ciò migliora le prestazioni,

  • prova a trovare alcune opzioni di mount in linux, o alcune impostazioni dell’SSD, che miglioreranno le prestazioni.

Utensili

  • zerofree è uno strumento efficace per i file system ext . Vedi questo link,

    manpages.ubuntu.com/manpages/zesty/man8/zerofree.8.html

  • Altrimenti (se controlli e raddoppii, che tutto è corretto) puoi usare dd per creare un enorme file blank contenente zeri e cancellarlo in seguito (lento ma funziona in tutti i file system).

    Avvio da un’altra unità, ad esempio un’unità USB live

     cd  # for example: cd /mnt sudo dd if=/dev/zero of=blank bs=4096 

    Lascialo correre fino a quando non si ferma perché l’unità è piena e in seguito rimuovere il file blank . Ciò presuppone che non ci siano file utili con il nome già blank .

     sudo rm blank 

    Attenzione: dd è uno strumento potente ma pericoloso, quindi controlla e ricontrolla che non distruggerai dati importanti. Per giocare in questo caso è necessario eseguire il backup di tutto ciò che è prezioso sulle unità connesse in un’altra posizione (ad esempio su un’unità esterna che viene disconnessa in seguito).

Pulire l’intero dispositivo

Il mio metodo per le pendrive USB è quello di cancellare l’intero dispositivo (non solo lo spazio libero tra i file in una partizione parzialmente piena). Penso che questo sia il metodo più efficiente per le pendrive, ma penso che ci dovrebbe essere qualche impostazione di scarto, che funzioni efficientemente in un SSD senza cancellare l’intero dispositivo. Ad ogni modo, se vuoi testare, puoi provarlo, e poi creare una nuova tabella delle partizioni e una partizione ext4 . Vedi questo link

help.ubuntu.com/community/mkusb/wipe#Wipe_the_whole_device

Volevo aggiungere un commento in risposta all’eccellente post di @sudodus, ma al momento sono ancora 4 i rep reponsposti di poter commentare, quindi inseriscilo qui:

Per quanto riguarda il lasciare le cose inattive – con la tecnologia eMMC su cui ho lavorato (ancora, dovrebbe essere simile ma non identico al tuo), questo non avrebbe funzionato, dato che il dispositivo doveva supporre che i progettisti del sistema potessero tagliare il core power e andarsene il potere di IO vivo.

Esiste in realtà una modalità di sospensione per coordinare i risparmi energetici, ma ricordo i venditori di eMMC che affermavano di non voler semplicemente iniziare le operazioni in background nel bel mezzo del tempo, eseguono solo queste operazioni di pulizia tra l’accettazione di un comando lo invii e prima di restituire lo stato (risultato).

È ansible che gli SSD siano diversi, avendo un controller che, in particolare, durante il periodo di inattività, invia comandi al backend flash NAND che porta alla pulizia e al re-org dei blocchi di dati al suo interno. Ma non mi aspetterei necessariamente che ciò accada, in base alla mia esperienza.