zfs - Permanent errors

gadean · 5 März 2014

Hi,
ich bräuchte mal wieder eure Hilfe, ich nutze als Storage, für ein ESXi Server, ein FreeBSD 9.1 mit zfs Pool. Der Pool ist mittels nfs an den ESXi Server angebunden und via samba übers Netzwerk erreichbar, mittlerweile plagen mich jedoch die "Permanent errors ..." Meldungen. In unterschiedlichen Zeitabständen beim lesen von Files über samba bekomm ich unter Windows die Fehlermeldung "Die Anforderung konnte wegen eines E/A-Gerätefehlers nicht ausgeführt werden." und "zpool status -v tank" gibt mir dann die Meldung "errors: Permanent errors have been detected in the following files:".
Das beheben der Fehler ist ansich nicht das Problem, jedoch finde ich einfach nicht die Ursache. Was löst diese Probleme aus?

Der aktuelleste Fall: Snapshot vom ZVol erstellt und auf ein anderes ZVol gesendet um es dann via samba auf einem anderen Client zu sichern (USB 3.0 Platten mag der Server nicht weswegen die Snapshots über ein Windows Client auf die Externe geschrieben werden).

Grüße

Anbei noch ein paar Infos:

Code:

[root@stor01 /home/ohaucke]# uname -a
  FreeBSD stor01.home.local 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec  4 09:23:10 UTC 2012  root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
[root@stor01 /home/ohaucke]# zfs list
  NAME  USED  AVAIL  REFER  MOUNTPOINT
  tank  681G  1.12T  34.5K  /tank
  tank/datastore2  580G  1.12T  580G  /tank/datastore2
  tank/files  100G  1.12T  100G  /tank/files
[root@stor01 /home/ohaucke]# zpool status -v tank
  pool: tank
  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://illumos.org/msg/ZFS-8000-8A
  scan: scrub repaired 0 in 1h43m with 0 errors on Fri Feb  28 19:38:49 2014
  config:
  NAME  STATE  READ WRITE CKSUM
  tank  ONLINE  0  0  4
  mirror-0  ONLINE  0  0  8
  ada1  ONLINE  0  0  8
  ada2  ONLINE  0  0  8
  mirror-1  ONLINE  0  0  0
  ada3  ONLINE  0  0  0
  ada4  ONLINE  0  0  0
  logs
  gpt/log  ONLINE  0  0  0
  cache
  gpt/cache  ONLINE  0  0  0
  errors: Permanent errors have been detected in the following files:
  /tank/files/datastore2_20140303.gz
[root@stor01 /home/ohaucke]# zfs get all tank
  NAME  PROPERTY  VALUE  SOURCE
  tank  type  filesystem  -
  tank  creation  Mon Aug  5 13:04 2013  -
  tank  used  681G  -
  tank  available  1.12T  -
  tank  referenced  34.5K  -
  tank  compressratio  1.00x  -
  tank  mounted  yes  -
  tank  quota  none  default
  tank  reservation  none  default
  tank  recordsize  128K  default
  tank  mountpoint  /tank  default
  tank  sharenfs  off  default
  tank  checksum  on  default
  tank  compression  off  local
  tank  atime  off  local
  tank  devices  on  default
  tank  exec  on  default
  tank  setuid  on  default
  tank  readonly  off  default
  tank  jailed  off  default
  tank  snapdir  hidden  default
  tank  aclmode  discard  default
  tank  aclinherit  restricted  default
  tank  canmount  on  default
  tank  xattr  off  temporary
  tank  copies  1  default
  tank  version  5  -
  tank  utf8only  off  -
  tank  normalization  none  -
  tank  casesensitivity  sensitive  -
  tank  vscan  off  default
  tank  nbmand  off  default
  tank  sharesmb  off  default
  tank  refquota  none  default
  tank  refreservation  none  default
  tank  primarycache  all  default
  tank  secondarycache  all  default
  tank  usedbysnapshots  0  -
  tank  usedbydataset  34.5K  -
  tank  usedbychildren  681G  -
  tank  usedbyrefreservation  0  -
  tank  logbias  latency  default
  tank  dedup  off  local
  tank  mlslabel  -
  tank  sync  standard  local
  tank  refcompressratio  1.00x  -
  tank  written  34.5K  -
[root@stor01 /home/ohaucke]# zfs get all tank/datastore2
  NAME  PROPERTY  VALUE  SOURCE
  tank/datastore2  type  filesystem  -
  tank/datastore2  creation  Tue Aug  6  9:52 2013  -
  tank/datastore2  used  580G  -
  tank/datastore2  available  1.12T  -
  tank/datastore2  referenced  580G  -
  tank/datastore2  compressratio  1.00x  -
  tank/datastore2  mounted  yes  -
  tank/datastore2  quota  none  default
  tank/datastore2  reservation  none  default
  tank/datastore2  recordsize  128K  default
  tank/datastore2  mountpoint  /tank/datastore2  default
  tank/datastore2  sharenfs  -maproot=root -network=10.220.210.1 -mask 255.255.255.0  local
  tank/datastore2  checksum  on  default
  tank/datastore2  compression  off  inherited from tank
  tank/datastore2  atime  off  inherited from tank
  tank/datastore2  devices  on  default
  tank/datastore2  exec  on  default
  tank/datastore2  setuid  on  default
  tank/datastore2  readonly  off  default
  tank/datastore2  jailed  off  default
  tank/datastore2  snapdir  hidden  default
  tank/datastore2  aclmode  discard  default
  tank/datastore2  aclinherit  restricted  default
  tank/datastore2  canmount  on  default
  tank/datastore2  xattr  off  temporary
  tank/datastore2  copies  1  default
  tank/datastore2  version  5  -
  tank/datastore2  utf8only  off  -
  tank/datastore2  normalization  none  -
  tank/datastore2  casesensitivity  sensitive  -
  tank/datastore2  vscan  off  default
  tank/datastore2  nbmand  off  default
  tank/datastore2  sharesmb  off  default
  tank/datastore2  refquota  none  default
  tank/datastore2  refreservation  none  default
  tank/datastore2  primarycache  all  default
  tank/datastore2  secondarycache  all  default
  tank/datastore2  usedbysnapshots  0  -
  tank/datastore2  usedbydataset  580G  -
  tank/datastore2  usedbychildren  0  -
  tank/datastore2  usedbyrefreservation  0  -
  tank/datastore2  logbias  latency  default
  tank/datastore2  dedup  off  inherited from tank
  tank/datastore2  mlslabel  -
  tank/datastore2  sync  standard  inherited from tank
  tank/datastore2  refcompressratio  1.00x  -
  tank/datastore2  written  580G  -
[root@stor01 /home/ohaucke]# zfs get all tank/files
  NAME  PROPERTY  VALUE  SOURCE
  tank/files  type  filesystem  -
  tank/files  creation  Fri Aug 23 17:22 2013  -
  tank/files  used  100G  -
  tank/files  available  1.12T  -
  tank/files  referenced  100G  -
  tank/files  compressratio  1.00x  -
  tank/files  mounted  yes  -
  tank/files  quota  none  default
  tank/files  reservation  none  default
  tank/files  recordsize  128K  default
  tank/files  mountpoint  /tank/files  default
  tank/files  sharenfs  off  default
  tank/files  checksum  on  default
  tank/files  compression  off  inherited from tank
  tank/files  atime  off  inherited from tank
  tank/files  devices  on  default
  tank/files  exec  on  default
  tank/files  setuid  on  default
  tank/files  readonly  off  default
  tank/files  jailed  off  default
  tank/files  snapdir  hidden  default
  tank/files  aclmode  discard  default
  tank/files  aclinherit  restricted  default
  tank/files  canmount  on  default
  tank/files  xattr  off  temporary
  tank/files  copies  1  default
  tank/files  version  5  -
  tank/files  utf8only  off  -
  tank/files  normalization  none  -
  tank/files  casesensitivity  sensitive  -
  tank/files  vscan  off  default
  tank/files  nbmand  off  default
  tank/files  sharesmb  off  default
  tank/files  refquota  none  default
  tank/files  refreservation  none  default
  tank/files  primarycache  all  default
  tank/files  secondarycache  all  default
  tank/files  usedbysnapshots  0  -
  tank/files  usedbydataset  100G  -
  tank/files  usedbychildren  0  -
  tank/files  usedbyrefreservation  0  -
  tank/files  logbias  latency  default
  tank/files  dedup  off  inherited from tank
  tank/files  mlslabel  -
  tank/files  sync  standard  inherited from tank
  tank/files  refcompressratio  1.00x  -
  tank/files  written  100G  -
[root@stor01 /home/ohaucke]# cat /etc/exports
  /tank/datastore2 -maproot=root 10.220.210.1
[root@stor01 /home/ohaucke]# cat /usr/local/etc/samba/smb.conf
  [GLOBAL]
  server string = stor01
  netbios name = stor01.home.local
  bind interfaces only = true
  interfaces = eth0 10.220.210.2
  encrypt passwords = true
  map to guest = Bad User
  guest account = nobody
  workgroup = WORKGROUPP
  security = user
  unix extensions = no
  nt acl support = yes
  inherit acls = no
  map acl inherit = yes
  disable netbios = Yes
  [datastore2]
  comment = "datastore2"
  path = /tank/datastore2
  writeable = no
  browseable = no
  user = root
  write list = ohaucke
  locking = no
  guest ok = no
  create mode = 0664
  directory mode = 0777
  public = no
  [files]
  comment = "Files"
  path = /tank/files
  writeable = no
  browseable = no
  user = root
  write list = ohaucke
  locking = no
  guest ok = no
  create mode = 0664
  directory mode = 0777
  public = no
[root@stor01 /home/ohaucke]#

kmh · 5 März 2014

Also als erstes würde ich da an eine defekte Festplatte denken?

gadean · 5 März 2014

Das Problem tritt bisher nur auf wenn ich via samba auf dem Pool agiere, direkt auf der Machine bzw. via nfs hatte ich bisher keine Probleme (wobei ich das selten mach). Es tritt zeitlich gesehen sehr unterschiedlich auf, mal kann ich in einer Woche 500GB+ hin und her schieben, dann gibts nen Tag da hab ich schon bei einer 300MB Datei das genannte Problem.

Kabel sitzen fest

Code:

SMART status:
Checking health of /dev/ada0: OK
Checking health of /dev/ada1: OK
Checking health of /dev/ada2: OK
Checking health of /dev/ada3: OK
Checking health of /dev/ada4: OK

kmh · 5 März 2014

Auch SMART kann lügen ...

Ist der Arbeitsspeicher in Ordnung?

gadean · 5 März 2014

Die Platten sind relativ neu (4x Hitachi Deskstar HDS721010CLA332 1TB *02.01.2013* - 1x Mushkin Chronos Deluxe 2,5" SSD 120 GB *07.08.2013*) und die Hitachis laufen bei mir privat seit 2 Jahren 24/7 ohne Probleme *weswegen ich die auch für den Storage gekauft habe*, beim Arbeitsspeicher bin ich mir nicht sicher, den müsste ich heute Abend mal testen. Würde mich aber wundern wenn der Probleme macht, wie gesagt, tritt das bisher nur auf wenn ich via samba auf Daten zugreife.

kmh · 5 März 2014

ZFS findet Fehler .... das Problem solltest du als erstes Lösen. Ich vermute dass dies auch die Ursache ist.

Entweder deine Platten sind kaputt (zumindest eine) da der Fehler ja schon mehrfach auftauchte, die Kabel haben einen Knacks oder in deinem Speicher flippen bits. Wobei letzteres eher unwahrscheinlich ist, dann würde der Fehler auch noch andere Anwendungen betreffen.

gadean · 5 März 2014

Genau das habe ich ja vor

bevor ich jedoch das ganze System auseinander nehme und evtl. nur etwas falsch Konfiguriert ist, wollte ich eure Meinung dazu hören. Die Frage die sich mir stellt, wie überprüfe ich die Platten ohne mich auf die SMART Werte zu verlassen? Hast du da einen Vorschlag? Mir fällt keiner ein.

nakal · 5 März 2014

Hmm... guck mal genauer mit

Code:

smartctl -A /dev/DRIVE

wie die einzelnen Attribute aussehen.

Aber ein Fehler im Mirror an der gleichen Stelle auf beiden Laufwerken, sodass die Checksumme einer Datei getroffen wird? Das halte ich für sehr unwahrscheinlich, dass es ein Plattenfehler ist. Schau nochmal wie das Partitionslayout ist und mit dmesg, ob da schon was von GEOM als Warnung kommt. Es kommt vor, dass manche RAID-Controller Platten wiedererkennbar markieren und oft machen sie damit Daten kaputt (natürlich an exakt der gleichen Stelle).

gadean · 5 März 2014

Es ist nicht immer die gleich Datei an der gleichen Stelle betroffen, ich greife via samba auf das ZVol "files" zu und der Fehler entsteht erst wenn ich von dort Dateien lese, der onboard RAID-Controller ist deaktiviert und die Platten waren zuvor nirgendwo anders angeschlossen. Die genauen SMART Werte hatte ich mir angeschaut, jedoch nichts besorgniserregendes gefunden (oder ich hab es übersehen). Die Platten haben kein Partitionslayout (sie hängen "roh" im Pool - ich wusste es damals nicht besser und sah bisher keinen Grund das zu ändern da die Platten in dem Server bleiben bis sie "sterben").

Code:

[root@stor01 /home/ohaucke]# dmesg
pid 96066 (smbd), uid 0: exited on signal 6
pid 96069 (smbd), uid 0: exited on signal 6
pid 96070 (smbd), uid 0: exited on signal 6
pid 96071 (smbd), uid 0: exited on signal 6
pid 96072 (smbd), uid 0: exited on signal 6
pid 96073 (smbd), uid 0: exited on signal 6
pid 96074 (smbd), uid 0: exited on signal 6

Code:

[root@stor01 /home/ohaucke]# smartctl -A /dev/ada1
smartctl 6.2 2014-02-18 r3874 [FreeBSD 9.1-RELEASE amd64] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
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     0x000b   099   099   016    Pre-fail  Always       -       2
  2 Throughput_Performance  0x0005   136   136   054    Pre-fail  Offline      -       95
  3 Spin_Up_Time            0x0007   130   130   024    Pre-fail  Always       -       294 (Average 288)
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       36
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   140   140   020    Pre-fail  Offline      -       30
  9 Power_On_Hours          0x0012   100   100   000    Old_age   Always       -       5101
10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       36
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       37
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       37
194 Temperature_Celsius     0x0002   162   162   000    Old_age   Always       -       37 (Min/Max 18/46)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0

[root@stor01 /home/ohaucke]# smartctl -A /dev/ada2
smartctl 6.2 2014-02-18 r3874 [FreeBSD 9.1-RELEASE amd64] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
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     0x000b   100   100   016    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   137   137   054    Pre-fail  Offline      -       90
  3 Spin_Up_Time            0x0007   127   127   024    Pre-fail  Always       -       300 (Average 294)
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       36
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   140   140   020    Pre-fail  Offline      -       30
  9 Power_On_Hours          0x0012   100   100   000    Old_age   Always       -       5102
10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       36
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       39
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       39
194 Temperature_Celsius     0x0002   176   176   000    Old_age   Always       -       34 (Min/Max 18/42)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0

[root@stor01 /home/ohaucke]# smartctl -A /dev/ada3
smartctl 6.2 2014-02-18 r3874 [FreeBSD 9.1-RELEASE amd64] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
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     0x000b   100   100   016    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   136   136   054    Pre-fail  Offline      -       94
  3 Spin_Up_Time            0x0007   129   129   024    Pre-fail  Always       -       297 (Average 291)
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       36
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   140   140   020    Pre-fail  Offline      -       30
  9 Power_On_Hours          0x0012   100   100   000    Old_age   Always       -       5102
10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       36
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       40
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       40
194 Temperature_Celsius     0x0002   176   176   000    Old_age   Always       -       34 (Min/Max 18/41)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0

[root@stor01 /home/ohaucke]# smartctl -A /dev/ada4
smartctl 6.2 2014-02-18 r3874 [FreeBSD 9.1-RELEASE amd64] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
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     0x000b   098   098   016    Pre-fail  Always       -       65539
  2 Throughput_Performance  0x0005   137   137   054    Pre-fail  Offline      -       91
  3 Spin_Up_Time            0x0007   127   127   024    Pre-fail  Always       -       300 (Average 294)
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       36
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   140   140   020    Pre-fail  Offline      -       30
  9 Power_On_Hours          0x0012   100   100   000    Old_age   Always       -       5102
10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       36
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       39
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       39
194 Temperature_Celsius     0x0002   157   157   000    Old_age   Always       -       38 (Min/Max 18/47)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0

nakal · 5 März 2014

SMART sieht ok aus.

Platten sollten immer ein Partitionslayout haben. Das kann sonst ganz "lustige" Effekte haben, die denen in deinem Fall ähneln. Schau mal im syslog was los ist, auch bei den älteren archivierten Logs. Schau nach Warnungen von GEOM. Hoffentlich hast Du nichts fuse-artiges am Laufen was noch dazwischenfunken kann.

Wie ist denn der Controller des Servers konfiguriert? Läuft er im HBA-Modus sind es getrennte, eigenständige Platten?

gadean · 5 März 2014

Damals wusst ich es nicht besser :/ jetzt bin ich zumindest in der Hinsicht weiter

( http://bsdforen.de/threads/zfs-mit-geli-gibt-es-eine-bessere-vorgehensweise.29870/ )
Nein die sind als eigenständige Platten angeschlossen. Die logs sind abgesehen davon das samba mir immernoch "unknown tag type 64" wirf ok. Dachte eig das hätte ich mittlerweile behoben durchs eintragen von

Code:

  unix extensions = no
  nt acl support = yes
  inherit acls = no
  map acl inherit = yes

Code:

...
Mar  5 16:59:55 stor01 smbd[43957]: [2014/03/05 16:59:55.833697,  0] modules/vfs_posixacl.c:170(smb_ace_to_internal)
Mar  5 16:59:55 stor01 smbd[43957]:   unknown tag type 64
Mar  5 17:20:26 stor01 smbd[43957]: [2014/03/05 17:20:26.375146,  0] modules/vfs_posixacl.c:170(smb_ace_to_internal)
Mar  5 17:20:26 stor01 smbd[43957]:   unknown tag type 64
Mar  5 17:38:47 stor01 smbd[43957]: [2014/03/05 17:38:47.180689,  0] modules/vfs_posixacl.c:170(smb_ace_to_internal)
Mar  5 17:38:47 stor01 smbd[43957]:   unknown tag type 64

Das fuse module ist nicht geladen (sofern du das meintest)

Code:

[root@stor01 /var/log]# kldstat
Id Refs Address            Size     Name
1   22 0xffffffff80200000 1323388  kernel
2    1 0xffffffff81524000 29e0     coretemp.ko
3    1 0xffffffff81612000 13436d   zfs.ko
4    1 0xffffffff81747000 2fb1     opensolaris.ko
5    1 0xffffffff8174a000 3dff     linprocfs.ko
6    1 0xffffffff8174e000 1f417    linux.ko

linprocfs und linux sind wg. htop geladen

nakal · 5 März 2014

Was meinst Du mit "files" sei ein zvol? Ist doch ein normales ZFS, oder? Also Samba oder NFS auf einem ZFS kann keine Inkonsistenz hervorrufen. Da versagt das ZFS an sich oder es ist ein Hardware-Schaden oder es funkt was dazwischen.

gadean · 5 März 2014

"tank" ist der gesamte pool, "tank/datastore2" und "tank/files" sind ein zvolumen. "tank/datastore2" ist mittels nfs und smb freigegeben - "tank/files" nur mittels smb
Das smb bzw. nfs für die inkonsistenz verantwortlich sind meinte ich auch nicht, es ist mir nur aufgefallen das es nur auftritt wenn ich mittels smb freigabe daten lese.

Beim jetztigen wars wie folgt: ich rief "zpool status -v tank" auf und hatte keine Fehler, danach fing ich an die Datei "/tank/files/datastore2_20140303.gz" auf meinen Windows Client zu kopieren (über die smb Freigabe), bei etwa der Hälfte brach er mit der Meldung "Die Anforderung konnte wegen eines E/A-Gerätefehlers nicht ausgeführt werden." ab, "zpool status -v tank" zeigte mir danach den Fehler an.
Das ist das was ich meinte, ich kann es nicht nachvollziehen, das Problem müsste doch beim schreiben auftreten? Warum bekam ich dann nicht schon vor dem Kopieren die Meldung das ein Fehler vorliegt?

nakal · 6 März 2014

Naja, auch wenn "files" ein blanker Datenträger-Container ohne Dateisystem ist, sollte ZFS das ebenfalls konsistent hinkriegen, egal welchen Müll man in das zvol-Laufwerk dann schreibt und egal welches Dateisystem drin ist, ob NTFS oder FAT oder was auch immer. Es könnten höchstens Dateisystemfehler im benutzen Dateisystem auftauchen, aber nicht im zpool.

"zpool status" schreibt aber nur eine Zusammenfassung der bisher gefundenen Fehler. Wenn Du den Pool auf aktuellen Zustand überprüfen möchtest, dann musst Du schon "zpool scrub" benutzen. Es korrigiert auch gleichzeitig alle gefundenen Probleme. Einen Fehler findet ZFS stets nur beim Lesen, nicht beim Schreiben, aber passieren tut der Fehler nur beim Schreiben. Mit dem Scrubben kannst Du nach dem Schreibzugriff nochmal alles kontrollieren.

gadean · 6 März 2014

Alles klar, gut ich werd mich dann am Wochenende mal hinsetzten und die Kabel austauschen, RAM testen und den Pool etwas überarbeiten.
Wo könnte ich noch nach Fehlern suchen? Beim Mainboard bzw. dem SATA Controller?

Yamagi · 6 März 2014

Die sinnvollste Reihenfolge wäre meiner Erfahrung nach:
1. Festplatten
2. Kabel / Backplane
3. RAM
4. Alles andere

kira12 · 7 März 2014

ich hatte mal das Problem das das OS auf ZFS. Beim backup von Datenpool zu Backuppool per rsync wurde der Ram knapp und die Kiste stützte ab wegen zu wenig Ram, also die Kombination aus OS auf ZFS uns rsync war nicht ideal. Vielleicht geht das bei dir auch in diese Richtung?

Gruß ré

Bummibaer · 9 März 2014

Hoi,

die Mushkin Chronos hatte in der Vergangenheit massive Probleme. Dafür gibts vom Hersteller eine neue Firmware. Prüf mal ob Du die aktuelle Firmware da auch verwendest.

Gruß Bummibär

gadean · 9 März 2014

So ich hab wahrscheinlich das Problem gefunden, ein RAM-Riegel mochte wohl nicht mehr so ganz. Hab Memtest mal laufen lassen, danach den betreffenden Riegel ausgetauscht und nochmals laufen lassen (ohne Fehler).

foxit · 10 März 2014

Jepp klasischer Fall eines defekten RAM's

nakal · 10 März 2014

Wahrscheinlich ist gut... das war das Problem! Wenn schon memtest was findet, dann ist endgültig alles verloren. Normalerweise findet es nämlich einen Speicherfehler gar nicht.

Yamagi · 10 März 2014

Und genau daher könnte Intel auch gern ECC-RAM auf der Desktoplattform anbieten...

gadean · 10 März 2014

Naja mit "wahrscheinlich" meinte ich das bisher noch kein Fehler aufgetreten ist, aber daraus kann man nicht automatisch schließen das es "nur" am defekten RAM lag, könnte noch zusätzlich ein defektes Kabel oder was auch immer sein (man weiss ja nie)

aber bisher lief aber alles ohne Probleme.

Danke an alle

-Nuke- · 10 März 2014

Yamagi schrieb:
Und genau daher könnte Intel auch gern ECC-RAM auf der Desktoplattform anbieten...

Naja, da AMD das ja auch nicht wirklich tut, besteht dort halt auch kein Zugzwang. Es können zwar mehr AMD CPUs ECC, aber ein Großteil (alle?) der Desktop-Boards nicht.

Ich hätte aber auch lieber flächendeckend ECC-RAM. Aber eine Server-CPU (bzw. einen schwachen i3) will ich mir dann auch nicht leisten wollen.

Crest · 10 März 2014

Die CPUs können es. Leider gibt es kaum Mainboards die den ECC Support der CPU nutzen.

zfs - Permanent errors

Depp vom Dienst!

Well-Known Member

Depp vom Dienst!

Well-Known Member

Depp vom Dienst!

Well-Known Member

Depp vom Dienst!

Anfänger

Depp vom Dienst!

Anfänger

Depp vom Dienst!

Anfänger

Depp vom Dienst!

Anfänger

Depp vom Dienst!

Possessed With Psi Powers

Well-Known Member

Registered Schwarzbär

Depp vom Dienst!

Anhänge

Well-Known Member

Anfänger

Possessed With Psi Powers

Depp vom Dienst!

Well-Known Member

rm -rf /*

Wir schützen deine Privatsphäre