zpool status -> 512B statt 4069B

peterle

peterle

Forenkasper
Beim Update einer älteren Kiste, die mit mfsbsd 8 oder 9 installiert wurde, meldet zpool seit dem vorletzten Update folgenden Fehler:
Code: 
# zpool status
  pool: tank
 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: none requested
config:

  NAME  STATE  READ WRITE CKSUM
  tank  ONLINE  0  0  0
  mirror-0  ONLINE  0  0  0
  ada0p3  ONLINE  0  0  0  block size: 512B configured, 4096B native
  ada1p3  ONLINE  0  0  0  block size: 512B configured, 4096B native

errors: No known data errors

Nach allem, was ich so gegooglet habe, scheint man den Fehler nur auf die harte Tour mit einer Neuinstallation beheben zu können.

Nur frage ich mich, ob eine Neuinstallation mir dann nicht blöderweise den Fehler auch macht, wenn ich bei exakt diesem einen Rechner nicht besonders bei der Anlage des zpools darauf achte?

Generell müßte ich eigentlich eine Platte aushängen können, diese neu installieren und dann aus der alten Platte die Daten holen, um sie dann ebenfalls einzuhängen, aber soweit bin ich noch nicht und ohne Sicherung mache ich das auch lieber nicht.
 
Da das ein MIrror ist kannst du eigentlich problemlos eine Platte rausnehmen und sie wo anders reinstecken, dann bootest du das System mit einer Platte und guckst ob es noch lebt. Im anderen System machst dann die eine Platte platt, formatierst sie auf 4k und fügst sie dem richtigen system wieder hinzu. Nach einem replace Kommando resilvered das Sys System und danach kannst du dasselbe nochmal mit der ersten Platte machen.
Backups sollte man in jedem Fall haben, aber die brauchst du ja auch wenn du neuinstallierst.
 
Naja... rate niemandem, dass es "problemlos" sei, auf Redundanz zu verzichten, insbesondere nicht, wenn die übriggebliebene Platte eine erhöhte Last erfahren wird, beim Resilvern. Besser wäre temporär eine andere Platte zuerst hinzuzufügen und dann die andere entfernen. Aber egal was man macht, wenn man klug ist, sollte man stets ein Backup parat haben. Ein falscher Handgriff und die Daten sind weg.

Und bei Neuinstallation wird geom_nop benutzt und auf jeden Fall wird alles auf 4k-Alignment installiert. Wenn man die Installation per Hand macht, sollte man ebenfalls das Tool gebrauchen, um das System zu zwingen, solch ein modernes Alignment zu wählen.
 
Seit FreeBSD 10.1 lässt sich das Alignement viel einfacher erzwingen:
Code: 
sysctl vfs.zfs.min_auto_ashift=12
 
Das muss vor dem Erstellen des VDEVs gesetzt sein. Du kannst nicht nachträglich den ashift eines VDEVs ändern. Um den ashift zu ändern musst du einen neuen Pool erstellen. Du kannst allerdings dein ganzes System mit zfs send/recv übertragen. Die Partitionstabelle und der Bootloader müssen auch noch auf die Platte um davon zu booten.
 
Ja, kannst du. In 11-CURRENT ist übrigens auch gerade das "Big Blocks" Feature eingeflossen, was es ZFS erlaubt nach oben über die 128K Blockgröße hinweg zu skalieren. Allerdings kann der Bootloader (derzeit) Dateien auf Blöcken >128K (derzeit) nicht lesen, weshalb man von entsprechenden Datasets nicht booten kann. Xin Li schrieb dazu:
Code: 
Log:
  MFV r274273:
  
  ZFS large block support.
  
  Please note that booting from datasets that have recordsize greater
  than 128KB is not supported (but it's Okay to enable the feature on
  the pool).  This *may* remain unchanged because of memory constraint.
  
  Limited safety belt is provided for mounted root filesystem but use
  caution is advised.
  
  Illumos issue:
      5027 zfs large block support
  
  MFC after:	1 month
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben