Presentazione nuovo Lab!

[Venturer]

Grazie per la precisazione comunque: Non avendo la scatola della CPU non potevo saperlo.

Inviato dal mio Redmi 4 Prime utilizzando Tapatalk

Io il mio THREARIPPER 12 core l'ho preso nuovo! Deduco che tu l'hai preso usato!

Quanto lo hai pagato?

Questo sistema mi deve durare minimo 10 anni come il precedente! Pensavo tra qualche anno quando il THREADRIPPER 2 32 core sará a prezzi molto bassi di fare un upgrade della CPU. Ma non ci vorró spendere piú di 200euro. Adesso il THREADRIPPER 32 core é ancora sopra i 1000 euro...

A proposito: il tuo TR 32 CORE quanto consuma? Hai fatto dei test in WATT?

La cosa buona del 12 CORE che oltre ad essere il piú economico in fatto di prezzo é anche il piú economico in fatto di consumi.....ti fa risparmiare!

[frakka]

In realtà il mio non è il 2990WX in commercio ma un 2990X... Sicuramente un esemplare pre-sales anche se HwInfo lo rileva come "Production Unit" quindi probabilmente uno degli ultimi step.
L'ho preso da un conoscente fidato, ho speso meno di quello che avrei speso per un Ryzen 9 3x di fascia alta.

Il mio precedente i 10 anni li ha fatti in effetti (PhenomII 1090T), anche se non mi aspettavo durasse così tanto... Spero che li faccia anche questo!

Questo ha un TDP di 250W. L'unica verifica che ho fatto è stato leggere tramite HwInfo l'assorbimento misurato con tutti i core impostati a 3,7Ghz: Sotto CineBench il socket assorbiva circa 290W...

[frakka]

Visto che la situazione Coronavirus è ancora lontana dal risolversi, è probabile che dovremo prorogare lo smartworking di mia moglie quindi la VGA del lab mi serve in casa...

Ok, è una scusa: Ne ho approfittato e ho preso dal solito cugino una EVGA GeForce GTX 1060 SuperClocked 6Gb!!!

A questo punto, però si è posto un dilemma... La scheda è dual slot e posizionandola al posto della precedente (nello slot 3) mi sarei bruciato un sacco di posto, coprendo completamente lo slot 8x sottostante.
Ho deciso quindi di montarla nello slot numero 1, rassegnandomi a traslare verso l'altro il dissipatore. Come accennato in precedenza, il Noctua prevede questa possibilità, essendo dotato di 3 posizioni di regolazione che permettono di traslare "verso nord" il corpo del dissipatore, che altrimenti andrebbe a toccare il retro della scheda video.

Ho quindi traslato il dissipatore facendolo scorrere nella posizione centrale... Certo che Noctua poteva mettere un brugola 1cm più lunga nella confezione: Con quella in dotazione (che non è neppure magnetica) si fa davvero fatica a svitare e soprattutto a rimettere a posto quei 4 bulloncini (due per lato).
Ho quindi recuperato circa 3mm di distanza tra VGA e corpo del dissipatore: Direi che servivano tutti...

Avevo già accennato a questa possibilità nei primi post, dicendo che ci avevo rinunciato perchè lasciava scoperta un piccola porzione dell'HIS della CPU... Amen!

Diversamente avrei finito per giocarmi molto dello spazio a disposizione per i prossimi arrivi...

[lucagiordan]

wow complimenti

[frakka]

Grazie!!

Ieri sera stavo installando la gold (immagine base pronta per essere replicata a stampino) di una macchina virtuale con Windows server 2019... Il tutto era talmente veloce che mi sono quasi commosso!!

E sto ancora usando solo la ssd "standard performance" perché sullo NVMe volevo fare ancora qualche test con Cristal Disk mark prima di iniziare a usarlo davvero.

Inviato dal mio Redmi 4 Prime utilizzando Tapatalk

[frakka]

[EDIT:]

Ho condensato i test effettuati qui.

[Trattore]

Ciao frakka, scusa la mia ignoranza: cosa significa con namespace formattato a 4K?

[frakka]

Allora: Ci sto ancora studiando, non ne ho compreso appieno tutte le implicazioni/potenzialità ma è una cosa che può essere di interesse più per l'ambiente enterprise che per l'ambiente desktop.

Il "namespace" è un layer aggiuntivo che si posiziona tra i blocchi fisici della memoria ed il volume grezzo non partizionato. A quanto mi risulta, non esisteva con i dischi ATA ma è stato introdotto con le memorie a stato solido come le NVME (non sono sicuro se anche negli storage PCI-Express in generale).

Questo è la struttura dei dispositivi a blocchi del mio lab:


Come si vede nell'immagine, i dischi meccanici/SSD tradizionali sono rappresentati da un device indicato da "sd" seguito da una lettera (sda, sdb, sdc ed sdd) e le partizioni al loro interno sono identificate da un numero sequenziale (1, 2, 3, 4, etc...). All'interno delle partizioni possiamo poi avere un'ulteriore layer software di gestione/aggregazione rappresentato ad esempio dai volumi. (laboratorio-root, laboratorio-ssd, etc...)

Le unità nvme, invece usano una nomenclatura diversa: L'unità di base su cui vengono posizionate le partizioni non è il device "nvme0" ma l'oggetto "nvme0n1" dove "n1" è appunto il "namespace" in cui è suddiviso lo spazio di archiviazione gestito dal controller e su cui vengono poi costruite le partizioni. La teoria dice che un singolo drive nvme potrebbe essere suddiviso in più namespace, ognuno indipendente dall'altro. Addirittura lo spazio di archiviazione a disposizione del controller e che costituisce il namespace potrebbe non essere neppure "locale" al server ma distribuito all'interno del datacenter in macchine diverse, per costruire soluzioni di archiviazione distribuite particolarmente complesse. Oppure lo stesso namespace potrebbe essere spalmato su più drive all'interno dello stesso server.

In CentOS 8 è presente una utility generica per la gestione delle unità nvme che permette, tra le altre cose, di eseguire il secure erase delle unità o di aggiornarne i firmware (utile dato che il Sabrent non viene fornito con un software di gestione).
Spulciando tra le opzioni di questa utility ho visto che c'era una funzione di list che mostrava alcune informazioni sul drive:



Di default nella colonna "Format" il Sabrent riportava "512b".

Ricordi quando alcuni anni fa nei dischi meccanici è stata introdotta la dimensione del cluster a "4k" in sostituzione del precedente cluster da 512b? In pratica, nella unità nvme è come se si potesse scegliere la dimensione del cluster da utilizzare, impostando questa dimensione a livello di namespace.

Quali sono i vantaggi? Boh!
Non ho trovato molte indicazioni in merito in letteratura e allora stavo sperimentando... Sui dischi meccanici abbiamo assistito ad un aumento di velocità sensibile ma lì era presente proprio una differenza fisica a livello del piatto mentre in queste unità la dimensione della cella di memoria rimane quella quindi è solo un raggruppamento logico. Non mi è chiaro quali possano essere i vantaggi ma se si sono presi la briga di prevedere la possibilità di variare questo parametro, a qualcosa servirà! Inoltre una differenza prestazionale l'ho vista nel passaggio da una dimensione all'altra ma non posso ancora quantificare perchè non ho fatto un test preciso con pattern elevati (che quindi esulino dalla cache del drive) o disattivando la cache del drive.

La formattazione del namespace è distruttiva quindi per passare da una dimensione all'altra il disco deve essere vuoto.

La gestione di namespace multipli deve essere supportata dal controller e/o dal suo firmware e sembra che il Sabrent purtroppo non lo permetta.
Più namespace mi avrebbero permesso, ad esempio, di usare metà del Sabrent per la macchine virtuali della laboratorio e l'altra metà staccata dalla macchina fisica e magari passata a una o più macchine virtuali come se fosse un disco locale (mi sono spiegato? In pratica la macchina virtuale potrebbe prendere la gestione diretta del dispositivo nvme0nX come se fosse direttamente connessa alla macchina guest. Questo le permetterebbe di formattarla partizionarle o anche di eseguire il trim delle celle senza l'intermediazione della macchina fisica) senza la necessità di dedicare l'intero drive (che quindi vuol dire un interno "connettore" sulla scheda madre) a questo scopo.

[frakka]

Visto che ci siamo...
L'utility "nvme" permette anche di accedere ai log del drive:



Per eseguire il "Secure Erase" vediamo prima se il comando è supportato (l'output è molto lungo quindi lo tronco):

[root@laboratorio ~]# nvme id-ctrl -H /dev/nvme0
NVME Identify Controller:
vid : 0x1987
ssvid : 0x1987
sn : CD8E079B119E00657956
mn : Sabrent
fr : RKT303.2
rab : 1
ieee : 6479a7
cmic : 0
[3:3] : 0 ANA not supported
[2:2] : 0 PCI
[1:1] : 0 Single Controller
[0:0] : 0 Single Port

[...]

oacs : 0x17
[8:8] : 0 Doorbell Buffer Config Not Supported
[7:7] : 0 Virtualization Management Not Supported
[6:6] : 0 NVMe-MI Send and Receive Not Supported
[5:5] : 0 Directives Not Supported
[4:4] : 0x1 Device Self-test Supported
[3:3] : 0 NS Management and Attachment Not Supported
[2:2] : 0x1 FW Commit and Download Supported
[1:1] : 0x1 Format NVM Supported
[0:0] : 0x1 Security Send and Receive Supported
[...]
fna : 0
[2:2] : 0 Crypto Erase Not Supported as part of Secure Erase
[1:1] : 0 Crypto Erase Applies to Single Namespace(s)
[0:0] : 0 Format Applies to Single Namespace(s)
[...]

Esistono 2 tipologie di "Secure erase":



Dall'output del comando precedente nella sezione "fna" si vede che:
[2:2] : 0 Crypto Erase Not Supported as part of Secure Erase

Quindi il Sabrent supporta solo la "User Data Erase":

[root@laboratorio ~]# nvme format /dev/nvme0n1 --ses 1
Success formatting namespace:1

Infatti provare la modalità "2" restituisce una pigna:

[root@laboratorio ~]# nvme format /dev/nvme0n1 -s 2
NVME Admin command error:INVALID_FORMAT: The LBA Format specified is not supported. This may be due to various conditions(210a)

Quindi, se avessi più namespace, potrei eseguire il secure erase solo solo di una porzione del drive, specificando di quale namespace eseguire il secure erase.
L'utility prevede anche un'opzione "sanitize" :

Sanitize was introduced in NVMe 1.3 specification, so before then NVMe Format was used exclusively to perform secure erase. While both options work, Sanitize is more robust for ensuring the data was properly wiped; format is good for everyday use and testing.

Dovrebbe essere supportata dal Sabrent, che è compatibile nvme 1.3, ma non ho capito come dare il comando evidentemente perchè mi va in errore.

Adesso l'ho riportato a 512b:

[root@laboratorio ~]# nvme format /dev/nvme0n1 --b 512
Success formatting namespace:1
[root@laboratorio ~]# nvme list
Node SN Model Namespace Usage Format FW Rev
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1 CD8E079B119E00657956 Sabrent 1 1.02 TB / 1.02 TB 512 B + 0 B RKT303.2

Comunque il Sabrent prevede proprio il supporto alla lba 512 ed lba 4096. Ho visto screenshot di altri controller che riportavano per queste due misure diversi valori di "Metadt":

[root@laboratorio ~]# smartctl --all /dev/nvme0
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.18.0-147.5.1.el8_1.x86_64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number: Sabrent
Serial Number: CD8E079B119E00657956
Firmware Version: RKT303.2
PCI Vendor/Subsystem ID: 0x1987
IEEE OUI Identifier: 0x6479a7
Total NVM Capacity: 1,024,209,543,168 [1.02 TB]
Unallocated NVM Capacity: 0
Controller ID: 1
Number of Namespaces: 1
Namespace 1 Size/Capacity: 1,024,209,543,168 [1.02 TB]
Namespace 1 Formatted LBA Size: 512
Namespace 1 IEEE EUI-64: 6479a7 2a83153536
Local Time is: Sun Mar 15 01:53:10 2020 CET
Firmware Updates (0x12): 1 Slot, no Reset required
Optional Admin Commands (0x0017): Security Format Frmw_DL Self_Test
Optional NVM Commands (0x005d): Comp DS_Mngmt Wr_Zero Sav/Sel_Feat Timestmp
Maximum Data Transfer Size: 512 Pages
Warning Comp. Temp. Threshold: 75 Celsius
Critical Comp. Temp. Threshold: 80 Celsius

Supported Power States
St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat
0 + 7.13W - - 0 0 0 0 0 0
1 + 5.29W - - 1 1 1 1 0 0
2 + 4.36W - - 2 2 2 2 0 0
3 - 0.0490W - - 3 3 3 3 2000 2000
4 - 0.0018W - - 4 4 4 4 25000 25000

Supported LBA Sizes (NSID 0x1)
Id Fmt Data Metadt Rel_Perf
0 + 512 0 2
1 - 4096 0 1

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02, NSID 0xffffffff)
Critical Warning: 0x00
Temperature: 27 Celsius
Available Spare: 100%
Available Spare Threshold: 5%
Percentage Used: 0%
Data Units Read: 4,679,884 [2.39 TB]
Data Units Written: 4,267,643 [2.18 TB]
Host Read Commands: 191,536,440
Host Write Commands: 170,764,505
Controller Busy Time: 84
Power Cycles: 115
Power On Hours: 113
Unsafe Shutdowns: 32
Media and Data Integrity Errors: 0
Error Information Log Entries: 123
Warning Comp. Temperature Time: 0
Critical Comp. Temperature Time: 0

Ref:
https://metebalci.com/blog/a-quick-t...-express-nvme/
Secure Erase HDDs/SSDs(SATA/NVMe) using hdparm & nvme-cli on Linux | NotebookReview

[frakka]

Come non detto... Il Sabrent non supporta il "sanitize"...

[root@laboratorio ~]# nvme id-ctrl /dev/nvme0 -H |grep sanicap -A 5
sanicap : 0
[2:2] : 0 Overwrite Sanitize Operation Not Supported
[1:1] : 0 Block Erase Sanitize Operation Not Supported
[0:0] : 0 Crypto Erase Sanitize Operation Not Supported

Ref: https://nvmexpress.org/open-source-n...face-nvme-cli/