13.2 zu 14.1 Upgrade - zfs non-native block size (nvd->nda)

gadean

gadean

Depp vom Dienst!
Hey,
ich bräuchte mal euren Input.
Ich habe eben eine Maschine aktualisiert (13.2 -> 13.3 -> 14.1) und zfs spuckt jetzt folgende Meldung aus:
Code: 
  pool: zroot
 state: ONLINE
status: One or more devices are configured to use a non-native block size.
        Expect reduced performance.
action: Replace affected devices with devices that support the
        configured block size, or migrate data to a properly configured
        pool.
  scan: scrub repaired 0B in 00:00:02 with 0 errors on Sat Jun 15 03:01:14 2024
config:

        NAME        STATE     READ WRITE CKSUM
        zroot       ONLINE       0     0     0
          nda0p4    ONLINE       0     0     0  block size: 4096B configured, 16384B native

errors: No known data errors

FYI: Es handelt sich um eine Samsung SSD 980 500GB, M.2

Das hängt wohl damit zusammen, das mit 14.0 von nvd zu nda gewechselt wurde:
Code: 
# 14.0 Release Notes
NVMe disks are now nda devices by default, for example nda0; see nda(4). Symbolic links for the previous nvd(4)
device names are created in /dev. However, configuration such as fstab(5) should be updated to refer to the new
device names. Options to control the use of nda devices and symbolic links are described in nda(4).
bdc81eeda05d (Sponsored by Netflix)

Ich habe dazu auch folgenden Post auf einer Mailing list gefunden: nvd->nda switch and blocksize changes for ZFS

Das Problem ist nur, das ich daraus nicht wirklich schlau werde, zu der NVMe unterschiedliche Infos bezüglich der Sectorsize existieren und das Thema eh etwas fragwürdig ist (Thema 512e).

Code: 
$ zdb | grep ashift
            ashift: 12

$ sysctl vfs.zfs.min_auto_ashift
vfs.zfs.min_auto_ashift: 12

$ sysctl vfs.zfs.max_auto_ashift
vfs.zfs.max_auto_ashift: 14

$ sysctl hw.nvme.use_nvd
hw.nvme.use_nvd: 0

Code: 
$ smartctl -a /dev/nvme0
...
Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 +     512       0         0
...

Code: 
$ diskinfo -v /dev/nda0
/dev/nda0
        512             # sectorsize
        500107862016    # mediasize in bytes (466G)
        976773168       # mediasize in sectors
        16384           # stripesize
        0               # stripeoffset
        Samsung SSD 980 500GB   # Disk descr.
        S64DNL0T861318V # Disk ident.
        nvme0           # Attachment
        Yes             # TRIM/UNMAP support
        0               # Rotation rate in RPM

Code: 
$ geom -p nda0
Geom class: DISK
Geom name: nda0
Providers:
1. Name: nda0
   Mediasize: 500107862016 (466G)
   Sectorsize: 512
   Stripesize: 16384
   Stripeoffset: 0
   Mode: r2w2e4
   descr: Samsung SSD 980 500GB
   lunid: 002538d821a497ca
   ident: S64DNL0T861318V
   rotationrate: 0
   fwsectors: 0
   fwheads: 0

Lebe ich jetzt erst mal mit der Warnung, wechsel ich auf nvd zurück oder installiere ich neu mit ashift=14 (16K)?

Bis vor dem Update hatte ich keine Probleme und auch aktuell, sieht es eigentlich ganz gut aus.
Hab mal eine größere Datei von einem anderen Pool auf zroot kopiert:
Code: 
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zroot       4.47G   456G      0      0      0      0
zroot       4.47G   456G      0      0      0      0
zroot       4.47G   456G      0      0      0      0
zroot       4.47G   456G      0      0      0      0
zroot       4.47G   456G      0      0      0      0
zroot       4.47G   456G      0      0      0      0
zroot       4.47G   456G      0      0      0      0
zroot       4.47G   456G      0      0      0      0
zroot       5.27G   455G      0  6.44K      0   816M
zroot       5.27G   455G      0    680      0  85.1M
zroot       6.07G   454G      0  5.77K      0   731M
zroot       6.07G   454G      0  4.69K      0   601M
zroot       6.87G   453G      0  1.75K      0   216M
zroot       7.66G   452G      0  6.44K  3.99K   817M
zroot       7.66G   452G      0      0      0      0
zroot       8.46G   452G      0  6.45K      0   817M
zroot       8.46G   452G      0  3.12K      0   399M
zroot       9.26G   451G      0  3.33K  59.8K   418M
zroot       10.1G   450G      0  6.44K      0   817M
zroot       10.1G   450G      0      0      0      0
zroot       10.9G   449G      0  6.45K      0   818M
zroot       10.9G   449G      0     38      0  4.87M
zroot       11.7G   448G      0  6.40K      0   812M
zroot       11.7G   448G      0  4.34K      0   555M
zroot       12.5G   448G      0  2.11K  3.99K   262M
zroot       13.3G   447G      0  6.44K      0   817M
zroot       13.3G   447G      0      0      0      0
zroot       14.1G   446G      0  6.45K      0   817M
zroot       14.1G   446G      0  2.93K      0   375M
zroot       14.9G   445G      0  3.52K      0   443M
zroot       15.7G   444G      0  6.43K  55.9K   817M
zroot       15.7G   444G      0      0      0      0
zroot       16.5G   444G      0  6.44K      0   817M
zroot       16.5G   444G      0      0      0      0
zroot       17.3G   443G      0  6.44K      0   817M
zroot       17.3G   443G      0  4.25K      0   544M
zroot       18.0G   442G      0  2.19K  3.99K   273M
zroot       18.8G   441G      0  6.43K      0   816M
zroot       18.8G   441G      0      0      0      0
zroot       19.6G   440G      0  6.45K      0   818M
zroot       19.6G   440G      0      0      0      0
 
Ich würde mir da keine Gedanken machen. Bisher hat die Performance ja gepasst, maximal wird die native Blocksize nun richtig erkannt und es könnte mit einem richtig allignten Device noch besser sein. Was native Blocksizes bei SSDs sind ist aber sowieso immer etwas schleierhaft, auch kann das durchaus asynchron sein (read/write). Auf die Schnelle hätte ich jetzt auch nichts zu deiner SSD gefunden, nur dass sich die Spezifikationen wohl auf 4k beziehen.

Vorausgesetzt natürlich, es ist nicht wirklich in Bug im nda Treiber.
 
gadean schrieb:
Lebe ich jetzt erst mal mit der Warnung, wechsel ich auf nvd zurück oder installiere ich neu mit ashift=14 (16K)?
Zum Vergrößern anklicken....
Laut dem FreeBSD Forum verschwindet die Warnung mit zurückwechseln auf nvd, z.B. mittels hw.nvme.use_nvd=1 und die Performance passt auch wieder; entweder das oder (bei Gelegenheit) neu mit neuer ashift installieren, was anderes bleibt scheinbar nicht.
 
Ich denke fürs erste werde ich tatsächlich auf nvd zurückwechseln und damit den eventuellen Fehler nicht mehr sehen, hat ja bisher auch gut funktioniert, aber es hinterlässt trotzdem ein faden Beigeschmack.

Es ist und bleibt einfach ein drecks Thema.
 
Die 980 Pros können keinen 4k-namespace, was man so ergooglen kann (in den specs sollte das stehen, da finde ich aber nichts). smartctl bestätigt das, braucht man dann pro ultra doppel-plus AAA? :confused:
Interessant wären die gleichen Ausgaben mit einer passenden SSD und einem 4k-namespace, die stripesize von 16k erschließt sich mir nicht sonderlich bei 512.
 
Ich denke nicht?
Vor dem Update hatte ich das nie getestet, nach dem Update konnte ich keinen Unterschied zwischen nvd und nda feststellen und bei beidem zeigt mir zpool iostat um die 800-900M an.
 
Dann würd ichs wie gesagt einfach lassen, ob du 4k Blöcke mit nda oder nvd schreibst wird egal sein. Eventuell holst du etwas mehr raus wenn du mit neuem ashift auf nda anlegst.
 
gadean schrieb:
@mr44er Da bin ich raus :D Ich hab zwar von Namespaces gehört/gelesen, aber so richtig erschließt sich das mir nicht.
Zum Vergrößern anklicken....
Ganz einfach, mindestens ein namespace muss zugeteilt sein und betrachte es als eine Art prä-Partition mit viel mehr Features. ;)

Edit:
unix.stackexchange.com

What are nvme namespaces? How do they work?

I've recently begun supporting Linux installed on devices with built-in nvme ssds. I noticed the device files had an extra number, beyond a number identifying the drive number and the partition num...
unix.stackexchange.com unix.stackexchange.com

Managing Nvme Namespaces

Manage your nvme device
narasimhan-v.github.io

Vielleicht1 wird das danach etwas klarer mit 512 vs 4096 und wie das zusammenspielt. Vielleicht2 willst du danach einfach eine NVMe für Männer kaufen :p
 
Ok also für mich als Konsumer einfach nur ein weiterer Layer, zwischen dem physikalischen Speicher und dem Dateisystem.
Was ich daran aber, in dem Kontext, nicht verstehe ist: Wie kann ein Namespace die Sector size ändern?

Wenn der Speicherchip die Daten in sagen wir mal 16k Blöcken schreibt, der Namespace daraus aber 4k macht, wird doch trotzdem jedes mal ein 16k Block geschrieben?

PS: Kannst du denn welche empfehlen? :D
 
gadean schrieb:
Ok also für mich als Konsumer einfach nur ein weiterer Layer, zwischen dem physikalischen Speicher und dem Dateisystem.
Zum Vergrößern anklicken....
Genau.

gadean schrieb:
Was ich daran aber, in dem Kontext, nicht verstehe ist: Wie kann ein Namespace die Sector size ändern?
Zum Vergrößern anklicken....
Wie das auf den Chips nach innen genau gemacht wird, bleibt meist Geheimnis vom Hersteller und die Firmware 'präsentiert' das dann einfach zum OS hin anders. SAS-Platten kann man oft auch anders definieren mit der sector size, danach muss sollte man aber einmal langsam formatieren, damit jeder Sektor neu geschrieben wurde und der counter für bad blocks aktuell ist.

gadean schrieb:
Wenn der Speicherchip die Daten in sagen wir mal 16k Blöcken schreibt, der Namespace daraus aber 4k macht, wird doch trotzdem jedes mal ein 16k Block geschrieben?
Zum Vergrößern anklicken....
Normalerweise will man für besten Durchsatz, geringen overhead und wenig Verschnitt (in einem Schrank fährst du mit zwei großen Schubladen besser als mit 16 kleinen, gleiche Materialdicke vorausgesetzt) immer die größte block/sector size aller beteiligten Komponenten. Ich bin nicht auf der Höhe der Zeit, aber mir sind jetzt auch noch keine 8k-SSDs bekannt und mir fehlt da etwas Hintergrundwissen mit diesem Treiberwechsel und was die stripe size von 16k da überhaupt will/soll und ob das so seine Richtigkeit hat.

gadean schrieb:
Kannst du denn welche empfehlen?
Zum Vergrößern anklicken....
Ich habe keine Langzeiterfahrung mit sowas (da tu' ich mir immer schwer mit Empfehlungen), nicht viele im Einsatz und auch keine Erfahrung mit unterschiedlichen Herstellern. Gebraucht habe ich was mit hoher Schreibbelastung, 4k definitiv und dann bei proxmox im Forum geguckt, was keine Probleme macht. Zufällig einen Schnapp bei Händlern/ebay gesehen und so wurden es 2x Micron7400 (MTFDKBG3T8TDZ) und 2x Micron7450 (MTFDKBA960TFR). Die ältesten haben jetzt knapp über 9100h runter, alles problemlos. Man muss nur genug kühlen, die Biester laufen heiß.
Vor dem Hintergrund mag man mit nem anderen Hersteller besser fahren, aber ggf. gibts ja noch mehr Empfehlungen/Vergleiche von den andereren hier.
Mein Punkt war hier, dass du dir für deinen Einsatzzweck mit ner anderen/geeignetereren NVMe definitiv was Gutes tun kannst, aber ich kann nicht abschätzen, ob die Samsung jetzt echte Probleme verursacht (sieht ja derzeit nicht danach aus). ;)
Edit: Die Microns wurde auch mit 512 geliefert, aber denen hab ich zunächst mal die neueste firmware verbraten und dann den namespace neu in 4k angelegt.
 
Ist zwar für Linux, aber vielleicht ganz interessant, wenn es jemand im Detail interessiert. Auch die weiterführenden Links.

NVMe physical block size – Thomas-Krenn-Wiki

SSDs speichern Daten in Speicherzellen, die in Pages zusammengefasst sind. Mehrere Pages bilden wiederum einen Block. Im Gegensatz zu Festplatten weisen SSDs daher keine physical_block_size aus. Der Linux Kernel berechnet seit Kernel Version 5.3 daher die physical_block_size aufgrund anderer...
www.thomas-krenn.com www.thomas-krenn.com
 
Cool, die haben sogar die 7450.
Btw. die gibt es als Pro und als Max (noch mehr von allem und Grund warum ich bei Samsung Pro doof guckte :D), aber Max war mir dann irgendwie doch zu oversized für daheim. Erstmal pro kaputtschreiben und ggf. wirds dann doch Max. ;)

Edit:
Kann nicht schaden, den Link mal wieder zu posten. Viel Info, ganz unten auch eine Liste mit getesteten Modellen.

Ceph performance — YourcmcWiki

yourcmc.ru yourcmc.ru
docs.google.com

SSD Bench

Bench Data Vendor,Model,Size, GB,Price, USD,journal iops,parallel random,non-txn random,linear write,Tested in,Tested in - details,Platform Transcend,ЕTS64GSSD370S,64,32,650,9000,80 Samsung,970 evo,250,60,530,22000,80000,324,PCIe 3.0 x4,PCIe Gen3 x4,ASUS B350 Plus Innodisk,SATADOM-SL 3ME3 V2,128,62
docs.google.com docs.google.com
 
Zuletzt bearbeitet:
Danke für die zusätzliche Infos/Links, es ist echt zum verrückt werden :D

Die von Micron hatte ich schon auf dem Schirm, genauso die neueren KIOXIA, wobei mir letztere etwas zu teuer sind.
Meine jetzigen SSDs müsste ich langsam mal austauschen (PowerOnHours 42356/Written 168294.24 GB/"Wearout" ~37%) ^^
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben