Frage zu zfs send ...

Midian

Well-Known Member
Hallöchen,

ich habe ein neues NAS System aufgesetzt, mit FreeBSD 9.0 und (momentan) einer einzelen 2TB Platte für den Datenspeicher. Mit dieser habe ich einen ZFS Pool angelegt, und speichere dort meine Daten.

Code:
rechner 1~> zfs list
NAME           USED  AVAIL  REFER  MOUNTPOINT
storage        210G  1.58T    32K  /storage
storage/data   210G  1.58T   210G  /storage/data

Nun möchte ich das Filesystem storage/data auf einen 2. Rechner per ssh sichern. Dazu gibt es diverse Howtos, und nicht zuletzt die Oracle Doku, leider bekomme ich es aber nicht so hin. Das übertragen eines Snapshots auf den 2. Rechner bricht immer nach einer Weile mit einem Fehler ab:

Code:
rechner1 ~> zfs send -Rv storage/data@fullbackup | ssh rechner2 "zfs recv -vFd storage"
sending from @ to storage/data@fullbackup
receiving full stream of storage/data@fullbackup into storage/data@fullbackup
warning: cannot send 'storage/data@fullbackup': Input/output error
cannot receive new filesystem stream: invalid stream (checksum mismatch)

Das ganze passiert nach etwa 6,1GB übertragenen Daten. Habe dann versucht, das ganze erst in ein File umzuleiten, und dieses dann von Hand auf Rechner 2 zu kopieren, aber auch hier der gleiche Fehler:

Code:
rechner1 ~> zfs send -R storage@fullbackup | gzip > /storage/data/backupfile.gz
warning: cannot send 'storage/data@fullbackup': Input/output error

Daher bin ich jetzt etwas überfragt. Mach ich hier was grundlegend falsch, oder wo liegt das Problem? :confused: :(
 

Yamagi

Possessed With Psi Powers
Teammitglied
Das klingt nach Datenkorruption auf der Quell-Festplatte. Schaue dir einmal die Ausgabe von "zpool status" an. Dort müsste man sehen können, ob es Lesefehler gab. Dann können wir weiterschauen.
 

Midian

Well-Known Member
Es gibt tatsächlich Fehler:

Code:
rechner1 ~> zpool status -v
  pool: storage
 state: ONLINE
status: One or more devices has experienced an error resulting in data
	corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
	entire pool from backup.
   see: http://www.sun.com/msg/ZFS-8000-8A
 scan: none requested
config:

	NAME        STATE     READ WRITE CKSUM
	storage     ONLINE       0     0     0
	  ada1      ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        <0x37>:<0x1c2f>
        storage/data@fullbackup:/Files/Bilder/2009 London/MVI_0568.MOV

Wie kam es dazu? Die Hardware ist nagelneu, ebenso wie die Installation. Die Daten (210GB) habe ich nach der Installation des Systems übers Netzwerk kopiert. Könnte das dabei passiert sein?

Und was mach ich jetzt dagegen? :)

[edit] Ich könnte schwören ich hab gestern mehrmals zpool status aufgerufen, und es waren noch keine Fehler :confused:
 

Yamagi

Possessed With Psi Powers
Teammitglied
Nein, beim Kopieren über das Netzwerk kann es nicht passiert sein. ZFS berechnet die Prüfsummen in dem Moment, an dem die Daten in den Pool kopiert werden. Nun ist natürlich guter Rat teuer. ich würde erst einmal die Kabel zur Festplatte abziehen, die Stecker durchpusten und wieder einstecken. Du wärst lange nicht die erste Person, die Kontaktprobleme mit S-ATA-Kabeln hat.
 

foxit

Well-Known Member
Dann kannst du noch deinen RAM mit "Memtest" prüfen. Nicht ECC RAM macht manchmal recht komische Sachen. Weiter vielleicht kontrollieren, ob die RAM Riegel im Mainboard richtig gesteckt sind (Reihenfolge beachten. z.B. bei insgesamt 6 Steckplätzen muss man meist den 1. und 4. stecken und nicht 1 und 2!)
 

Midian

Well-Known Member
Nein, beim Kopieren über das Netzwerk kann es nicht passiert sein. ZFS berechnet die Prüfsummen in dem Moment, an dem die Daten in den Pool kopiert werden. Nun ist natürlich guter Rat teuer. ich würde erst einmal die Kabel zur Festplatte abziehen, die Stecker durchpusten und wieder einstecken. Du wärst lange nicht die erste Person, die Kontaktprobleme mit S-ATA-Kabeln hat.

Kabel hab ich kontrolliert, schienen mir alle korrekt verbunden. War auch kein Staub/Dreck dran, ist ja wie gesagt alles komplett neu.

Der Fehler ist immer noch da, wie sollte ich jetzt testen ob alles funktioniert, bzw. wie soll ich den Fehler lösen?

Dann kannst du noch deinen RAM mit "Memtest" prüfen. Nicht ECC RAM macht manchmal recht komische Sachen. Weiter vielleicht kontrollieren, ob die RAM Riegel im Mainboard richtig gesteckt sind (Reihenfolge beachten. z.B. bei insgesamt 6 Steckplätzen muss man meist den 1. und 4. stecken und nicht 1 und 2!)

RAM Slots hab ich nur 2, die Riegel waren korrekt gesteckt.

[edit] memtest läuft nunmehr seit 3h ohne Fehler
 
Zuletzt bearbeitet:

namor

Imperator
Du könntest mal in die SMART Daten der Quell-Festplatte reinschauen. Hast du schon
Code:
zpool scrub
ausgeführt um nach weiteren Fehlern zu suchen?

PS.: Jemand sollte dringend mal die Fehlermeldungen von ZFS anpassen, die Links sind alle tot. Ein Mirror auf freebsd.org oder eine man-page wäre toll..

EDIT: Das einzige mal dass ich ZFS Fehler hatte war bei einer defekten Platte, ich kann mich aber nicht mehr erinner, ob's der gleiche Link war.
 

Midian

Well-Known Member
Ok, ich hab das jetzt mal angestoßen, und es läuft ziemlich langsam. Zumindest steigt die Restdauer jedesmal wenn ich drauf schaue ums doppelte:

Code:
20:01:01 root@epoch:~> zpool status -v
  pool: storage
 state: ONLINE
status: One or more devices has experienced an error resulting in data
	corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
	entire pool from backup.
   see: http://www.sun.com/msg/ZFS-8000-8A
 scan: scrub in progress since Thu Oct  4 19:24:50 2012
    8.44G scanned out of 211G at 1.85M/s, 31h5m to go
    0 repaired, 4.00% done
config:

Jedesmal sind es außerdem mehr Fehler, nun sind es schon 184 Fehler. (ist das normal, dass das so lange dauert .. ?)

smartctl zeigt mir:

Code:
20:57:34 root@epoch:~> smartctl -a /dev/ada1
smartctl 5.42 2011-10-20 r3458 [FreeBSD 9.0-RELEASE amd64] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Caviar Green (Adv. Format)
Device Model:     WDC WD20EARX-00PASB0
Serial Number:    WD-WCAZAF579190
LU WWN Device Id: 5 0014ee 2b1eecf2c
Firmware Version: 51.0AB51
User Capacity:    2,000,398,934,016 bytes [2.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   8
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Thu Oct  4 20:59:12 2012 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
See vendor-specific Attribute list for marginal Attributes.

General SMART Values:
Offline data collection status:  (0x80)	Offline data collection activity
					was never started.
					Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0)	The previous self-test routine completed
					without error or no self-test has ever 
					been run.
Total time to complete Offline 
data collection: 		(38580) seconds.
Offline data collection
capabilities: 			 (0x7b) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					Offline surface scan supported.
					Self-test supported.
					Conveyance Self-test supported.
					Selective Self-test supported.
SMART capabilities:            (0x0003)	Saves SMART data before entering
					power-saving mode.
					Supports SMART auto save timer.
Error logging capability:        (0x01)	Error logging supported.
					General Purpose Logging supported.
Short self-test routine 
recommended polling time: 	 (   2) minutes.
Extended self-test routine
recommended polling time: 	 ( 255) minutes.
Conveyance self-test routine
recommended polling time: 	 (   5) minutes.
SCT capabilities: 	       (0x3035)	SCT Status supported.
					SCT Feature Control supported.
					SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   032   032   051    Pre-fail  Always   FAILING_NOW 2686
  3 Spin_Up_Time            0x0027   173   172   021    Pre-fail  Always       -       6350
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       23
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       25
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       23
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       10
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       691
194 Temperature_Celsius     0x0022   119   114   000    Old_age   Always       -       31
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       202
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0

SMART Error Log Version: 1
ATA Error Count: 2613 (device log contains only the most recent five errors)
	CR = Command Register [HEX]
	FR = Features Register [HEX]
	SC = Sector Count Register [HEX]
	SN = Sector Number Register [HEX]
	CL = Cylinder Low Register [HEX]
	CH = Cylinder High Register [HEX]
	DH = Device/Head Register [HEX]
	DC = Device Command Register [HEX]
	ER = Error register [HEX]
	ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 2613 occurred at disk power-on lifetime: 25 hours (1 days + 1 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 60 41 16 e1  Error: UNC at LBA = 0x01164160 = 18235744

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 00 e0 40 16 e1 00      01:38:06.828  READ DMA
  c8 00 00 e0 40 16 e1 00      01:38:04.119  READ DMA
  c8 00 00 e0 40 16 e1 00      01:38:01.410  READ DMA
  c8 00 00 e0 40 16 e1 00      01:37:58.700  READ DMA
  c8 00 00 e0 40 16 e1 00      01:37:55.991  READ DMA

Error 2612 occurred at disk power-on lifetime: 25 hours (1 days + 1 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 60 41 16 e1  Error: UNC at LBA = 0x01164160 = 18235744

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 00 e0 40 16 e1 00      01:38:04.119  READ DMA
  c8 00 00 e0 40 16 e1 00      01:38:01.410  READ DMA
  c8 00 00 e0 40 16 e1 00      01:37:58.700  READ DMA
  c8 00 00 e0 40 16 e1 00      01:37:55.991  READ DMA
  c8 00 00 dd 35 16 e1 00      01:37:53.270  READ DMA

Error 2611 occurred at disk power-on lifetime: 25 hours (1 days + 1 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 60 41 16 e1  Error: UNC at LBA = 0x01164160 = 18235744

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 00 e0 40 16 e1 00      01:38:01.410  READ DMA
  c8 00 00 e0 40 16 e1 00      01:37:58.700  READ DMA
  c8 00 00 e0 40 16 e1 00      01:37:55.991  READ DMA
  c8 00 00 dd 35 16 e1 00      01:37:53.270  READ DMA
  c8 00 00 dd 35 16 e1 00      01:37:50.549  READ DMA

Error 2610 occurred at disk power-on lifetime: 25 hours (1 days + 1 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 60 41 16 e1  Error: UNC at LBA = 0x01164160 = 18235744

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 00 e0 40 16 e1 00      01:37:58.700  READ DMA
  c8 00 00 e0 40 16 e1 00      01:37:55.991  READ DMA
  c8 00 00 dd 35 16 e1 00      01:37:53.270  READ DMA
  c8 00 00 dd 35 16 e1 00      01:37:50.549  READ DMA
  c8 00 00 dd 35 16 e1 00      01:37:47.827  READ DMA

Error 2609 occurred at disk power-on lifetime: 25 hours (1 days + 1 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 60 41 16 e1  Error: UNC at LBA = 0x01164160 = 18235744

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 00 e0 40 16 e1 00      01:37:55.991  READ DMA
  c8 00 00 dd 35 16 e1 00      01:37:53.270  READ DMA
  c8 00 00 dd 35 16 e1 00      01:37:50.549  READ DMA
  c8 00 00 dd 35 16 e1 00      01:37:47.827  READ DMA
  c8 00 00 dd 35 16 e1 00      01:37:45.106  READ DMA

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]


SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.



Kann damit jemand was anfangen? Ist die Platte hinüber?
 

namor

Imperator
Code:
1 Raw_Read_Error_Rate     0x002f   032   032   051    Pre-fail  Always   FAILING_NOW 2686

Gut möglich dass die failed. Bin da kein Experte, aber SMART scheint READ Errors zu bemerken bei der Festplatte. Der scrub meckert auch rum, die READ Errors sind anscheinend problematisch. Ich habe mal nach SMART Read errors gegoogled und bin tatsächlich auf einen Post von yamagi hier im Forum gestoßen, wonach die READ Error Rate zwar sehr unterschiedlich zu interpretieren ist, bei WDC aber doch üblicherweise auf 0 bleibt.

EDIT: Yamagi schreibt aber auch klar, dass die RAW_ERROR_RATE im Grunde nichtssagend ist. Ich verweise auf den letzten Absatz.

Ich persönlich würde die HDD austauschen, oder zumindest den Pool von einem Backup auf eine _andere_ HDD spielen und überprüfen ob die Fehler dort auch auftreten.

Vielleicht äußert sich aber auch nochmal jemand mit mehr Erfahrung bei failenden HDDs.
 

Yamagi

Possessed With Psi Powers
Teammitglied
Wie ich immer so schön sage, ist SMART im Großen und Ganzen nutzlos. Es kann ein Hinweis auf den Zustand der Platte geben, eine klare Aussage lässt es aber nicht zu. In diesem Fall hat die "Raw Error Rate" den Threshold bereits durchschlagen, was zumindest ein deutlicher Fingerzeig ist, die Platte nicht mehr zu verwenden. Da die Platte nagelneu ist, würde ich mir auch gar nicht so viele Gedanken machen, sie stattdessen als defekt zurücksenden und gut ist. Und zwar an den Händler und nicht an den Hersteller.
 

Midian

Well-Known Member
So, ein kleines Update. Nachdem nun nach langer Wartezeit die neue HDD da ist, habe ich die Box nochmal eingerichtet, und das ganze nochmal versucht. Es klappt nun wunderbar, und ich kann wie gewollt meine Daten auf die Backup-Box sichern :)

Weitere Fragen habe ich dennoch:

Ich würde die ganze Prozedur gerne mit inkrementellem zfs send automatisieren. Dazu würde ich z.b. wöchentlich einen Snapshot anlegen, diesen dann inkrementell aufs Backup schieben. Da die Snapshots auch Platz brauchen, würde ich alte Snapshots gerne entsorgen. Kann man diese einfach löschen, oder bauen die Snapshots aufeinander auf?

Im Prinzip habe ich mir vorgestellt:

Code:
1) zfs snapshot -r storage/data@2012-11-14     // snapshot für diese woche
2) zfs send -R -i storage/data@2012-11-07 storage/data@2012-11-14 | ssh root@backup zfs receive -Fduv storage/data            // backup letzte woche - diese woche
3) zfs destroy 2012-11-01                      // snapshot vorletzer woche löschen

Damit hätte ich auf dem Quellsystem immer 2 Snapshots (aktuelle Woche, vorige Woche). Klappt das so?

Zweite Frage:

Auf der Backup-Box habe ich:

Code:
~> zfs list
NAME           USED  AVAIL  REFER  MOUNTPOINT
storage       59.5G  1.73T    32K  /storage
storage/data  59.5G  1.73T  59.5G  /storage/data

~> zfs list -t snapshot
NAME                      USED  AVAIL  REFER  MOUNTPOINT
storage@1                  20K      -    31K  -
storage/data@fullbackup    47K      -  59.5G  -

Müsste ich dann entsprechend auch hier die alten Snapshots löschen?
 

mark05

Well-Known Member
hi

warum neu entwickeln ? es git bei github ein zfs-replicate ( ich weis nicht ob es das gleiche
ist wie im ports )

1x im cron eingertragen und gut ist.

holger
 
Oben