Mengapa ZFS tidak melakukan apa-apa dengan sektor disk saya?


8

Saya mendapat kesan bahwa jika kesalahan I / O terjadi selama pembacaan dari kumpulan ZFS, dua hal akan terjadi:

  1. Kegagalan akan dicatat dalam statistik BACA atau CKSUM dari perangkat yang relevan, menyebar ke atas menuju level kumpulan.
    • Data yang berlebihan akan digunakan untuk merekonstruksi blok yang diminta, mengembalikan blok yang diminta ke pemanggil dan jika duff drive masih berfungsi, tulis ulang blok itu, ATAU
    • Kesalahan I / O akan dikembalikan jika data yang berlebihan tidak tersedia untuk memperbaiki kesalahan baca.

Tampaknya salah satu disk di pengaturan mirror saya telah mengembangkan sektor yang buruk. Itu dengan sendirinya tidak mengkhawatirkan; hal-hal seperti itu terjadi, dan itulah sebabnya saya memiliki redundansi (cermin dua arah, tepatnya). Setiap kali saya menggosok kumpulan atau membaca file dalam direktori tertentu (saya belum repot-repot untuk menentukan file mana yang salah), berikut muncul di dmesg, jelas dengan cap waktu yang berbeda-beda:

Nov  1 09:54:26 yeono kernel: [302621.236549] ata6.00: exception Emask 0x0 SAct 0x9c10 SErr 0x0 action 0x0
Nov  1 09:54:26 yeono kernel: [302621.236557] ata6.00: irq_stat 0x40000008
Nov  1 09:54:26 yeono kernel: [302621.236566] ata6.00: failed command: READ FPDMA QUEUED
Nov  1 09:54:26 yeono kernel: [302621.236578] ata6.00: cmd 60/a8:78:18:5a:12/00:00:5c:01:00/40 tag 15 ncq 86016 in
Nov  1 09:54:26 yeono kernel: [302621.236580]          res 41/40:a8:18:5a:12/00:00:5c:01:00/00 Emask 0x409 (media error) <F>
Nov  1 09:54:26 yeono kernel: [302621.236585] ata6.00: status: { DRDY ERR }
Nov  1 09:54:26 yeono kernel: [302621.236589] ata6.00: error: { UNC }
Nov  1 09:54:26 yeono kernel: [302621.238214] ata6.00: configured for UDMA/133

Debian Wheezy, kernel 3.2.0-4-amd64 # 1 SMP Debian 3.2.63-2 x86_64, ZoL 0.6.3. Versi paket terkini di debian-zfs = 7 ~ wheezy, libzfs2 = 0.6.3-1 ~ wheezy, zfs-dkms = 0.6.3-1 ~ wheezy, zfs-initramfs = 0.6.3-1 ~ wheezy, zfsutils = 0.6 .3-1 ~ wheezy, zfsonlinux = 3 ~ wheezy, linux-image-amd64 = 3.2 + 46, linux-image-3.2.0-4-amd64 = 3.2.63-2. Satu-satunya paket menyematkan yang saya tahu adalah untuk Zool, yang saya miliki (sebagaimana disediakan oleh paket zfsonlinux):

Package: *
Pin: release o=archive.zfsonlinux.org
Pin-Priority: 1001

Berjalan hdparm -Rdi drive melaporkan bahwa Write-Read-Verify dihidupkan (ini adalah Seagate, sehingga memiliki fitur itu dan saya menggunakannya sebagai jaring pengaman tambahan; latensi penulisan tambahan tidak menjadi masalah karena pola penggunaan interaktif saya sangat dibaca -berat):

/dev/disk/by-id/ata-ST4000NM0033-9ZM170_XXXXXXXX:
 write-read-verify =  2

Bahkan diberikan indikasi yang jelas bahwa ada sesuatu yang salah, zpool statusmengklaim bahwa tidak ada masalah dengan kolam:

  pool: akita
 state: ONLINE
  scan: scrub repaired 0 in 8h16m with 0 errors on Sat Nov  1 10:46:03 2014
config:

        NAME                        STATE     READ WRITE CKSUM
        akita                       ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            wwn-0x5000c50065e8414a  ONLINE       0     0     0
            wwn-0x5000c500645b0fec  ONLINE       0     0     0

errors: No known data errors

Kesalahan ini telah muncul di log secara teratur selama beberapa hari terakhir sekarang (sejak 27 Oktober) jadi saya tidak terlalu cenderung untuk menganggapnya hanya sebagai kebetulan. Saya menjalankan disk dengan timeout SCTERC cukup singkat; 1,5 detik dibaca (untuk pulih dengan cepat dari kesalahan baca), tulis 10 detik. Saya telah mengkonfirmasi bahwa nilai-nilai ini aktif pada drive yang dimaksud.

smartd terus mengganggu saya (yang dengan sendirinya adalah hal yang baik!) tentang fakta bahwa jumlah kesalahan ATA meningkat:

The following warning/error was logged by the smartd daemon:

Device: /dev/disk/by-id/ata-ST4000NM0033-9ZM170_XXXXXXXX [SAT], ATA error count increased from 4 to 5

For details see host's SYSLOG.

Berjalan smartctl --attributesdi drive yang dimaksud menghasilkan yang berikut:

smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.2.0-4-amd64] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   076   063   044    Pre-fail  Always       -       48910012
  3 Spin_Up_Time            0x0003   091   091   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       97
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   092   060   030    Pre-fail  Always       -       1698336160
  9 Power_On_Hours          0x0032   089   089   000    Old_age   Always       -       9887
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       98
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   095   095   000    Old_age   Always       -       5
188 Command_Timeout         0x0032   100   099   000    Old_age   Always       -       10
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   058   052   045    Old_age   Always       -       42 (Min/Max 20/45)
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       61
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       492
194 Temperature_Celsius     0x0022   042   048   000    Old_age   Always       -       42 (0 11 0 0)
195 Hardware_ECC_Recovered  0x001a   052   008   000    Old_age   Always       -       48910012
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Tidak ada yang mencolok dari yang biasa di sana. Perhatikan bahwa ini adalah drive perusahaan, jadi garansi lima tahun dan diperingkat untuk operasi 24x7 (artinya ini dapat diandalkan untuk lebih dari 40.000 jam operasi, dibandingkan dengan hanya di bawah 10.000 jam di bawah ikat pinggang sejauh ini). Perhatikan angka 5 pada atribut 187 Reported_Uncorrect; di situlah masalahnya. Perhatikan juga nilai Start_Stop_Count dan Power_Cycle_Count yang cukup rendah masing-masing di bawah 100.

Bukannya saya pikir itu relevan dalam kasus ini, tapi ya, sistem memang memiliki RAM ECC.

Properti non-default dari sistem file root di kumpulan adalah:

NAME   PROPERTY              VALUE                  SOURCE
akita  type                  filesystem             -
akita  creation              Thu Sep 12 18:03 2013  -
akita  used                  3,14T                  -
akita  available             434G                   -
akita  referenced            136K                   -
akita  compressratio         1.04x                  -
akita  mounted               no                     -
akita  mountpoint            none                   local
akita  version               5                      -
akita  utf8only              off                    -
akita  normalization         none                   -
akita  casesensitivity       sensitive              -
akita  usedbysnapshots       0                      -
akita  usedbydataset         136K                   -
akita  usedbychildren        3,14T                  -
akita  usedbyrefreservation  0                      -
akita  sync                  standard               local
akita  refcompressratio      1.00x                  -
akita  written               0                      -
akita  logicalused           2,32T                  -
akita  logicalreferenced     15K                    -

dan sesuai dengan kolam itu sendiri :

NAME   PROPERTY               VALUE                  SOURCE
akita  size                   3,62T                  -
akita  capacity               62%                    -
akita  health                 ONLINE                 -
akita  dedupratio             1.00x                  -
akita  free                   1,36T                  -
akita  allocated              2,27T                  -
akita  readonly               off                    -
akita  ashift                 12                     local
akita  expandsize             0                      -
akita  feature@async_destroy  enabled                local
akita  feature@empty_bpobj    active                 local
akita  feature@lz4_compress   active                 local

Daftar ini diperoleh dengan menjalankan {zfs,zpool} get all akita | grep -v default.

Sekarang untuk pertanyaan:

  1. Mengapa ZFS tidak melaporkan apa pun tentang masalah baca? Jelas pulih dari itu.

  2. Mengapa ZFS tidak secara otomatis menulis ulang sektor duff yang drive jelas mengalami kesulitan membaca, pada gilirannya diharapkan memicu relokasi oleh drive, mengingat bahwa ada redundansi yang cukup untuk perbaikan otomatis di jalur permintaan baca?


Saya tidak tahu. Mungkin Anda tidak memukul file yang terpengaruh. Atau mungkin tidak ada file yang terpengaruh pada saat ini.
ewwhite

@ewwhite Selama scrub, menjalankan yang telah berulang kali memicu kesalahan muncul di log sistem? (Kesalahan juga muncul ketika saya membakar satu set file ke DVD, yang awalnya saya lihat di sini.) Ada juga satu ton snapshot di kolam renang yang akan kembali.
CVn

Terpilih karena saya tidak yakin mengapa Anda menghadapi ini dengan ZFS - Mungkin menarik untuk melihat apakah ini bug ... Namun dari sudut pandang sysadmin, disk berputar adalah barang habis pakai. Saya memiliki disk yang DOA, mati dalam beberapa minggu, mati setelah satu tahun ... dan beberapa gagal pada 5 tahun. Jika Anda mencurigai ada masalah parah, ganti drive.
ewwhite

1
Baik. Apakah Anda juga memposting ke grup ZFS?
ewwhite

1
Saya tidak punya jawaban untuk Anda, tetapi saya telah melihat perilaku serupa di FreeBSD. Hard drive yang mengakibatkan kinerja menurun dan banyak kesalahan dicetak ke konsol, tetapi gagal menambah penghitung kesalahan tingkat zpool. Saya belum menemukan penjelasan, tetapi setidaknya mungkin layak untuk mempertimbangkan bahwa ini bukan fenomena khusus Linux.
Charley

Jawaban:


1

Saya menduga driver ATA mencoba lagi operasi baca beberapa kali ketika menerima kesalahan sebelum meneruskan kesalahan kembali ke driver sistem file.

Apa artinya ini adalah pada saat driver sistem file ZFS mendapatkan hasil dari membaca data semua ada di sana, dan benar, tetapi kemungkinan butuh waktu sedikit lebih lama dari biasanya. Tentu saja tidak ada penghitung kesalahan untuk latensi yang lebih tinggi dari rata-rata, jadi tidak ada yang dicatat.

Fakta bahwa nilai SMART untuk Reported_Uncorrect bukan 0 membuat saya curiga bahwa penyebab kegagalannya adalah disk itu sendiri, berbeda dengan mengatakan kabel SATA atau pengontrol SATA menjadi serpihan.

Jika ini masalahnya, kemungkinan besar disk pada akhirnya akan mati lebih banyak dan mulai gagal membaca bahkan setelah bagaimanapun banyak percobaan driver perangkat blok berusaha. Karena itu saran saya adalah mengganti disk.

Memicu tes SMART yang panjang kemungkinan akan gagal pada blok yang terpengaruh, jika Anda ingin membuat kesalahan hilang menulis ulang blok tersebut (dengan dd misalnya) harus menyebabkan disk untuk menukar sektor-sektor tersebut, tetapi menurut pengalaman saya sekali drive dimulai untuk pergi lebih baik hanya menggantinya dan selesai dengan itu.


0

Saya memiliki disk SCSI yang buruk dengan serangan ZFS pada Solaris. Saya memindai file-file log untuk informasi tentang pesan kesalahan untuk mengumpulkan bukti bahwa disk buruk dan meminta Oracle untuk menutupinya pada pemeliharaan perangkat keras. Saya menjalankan grep untuk string tertentu dalam log kesalahan dan baris-baris ini menunjukkan kesalahan disk akan di layar konsol saya. Ketika "Explorer" (log sistem dan alat pelaporan untuk Solaris) dijalankan dan dikirim ke Oracle, mereka mengatakan tidak ada kesalahan pada disk. Tapi saya memilikinya di riwayat layar saya. Saya memeriksa dan memang sudah hilang dari log pada disk.

Inilah yang sedang terjadi ... ZFS menjanjikan nol kesalahan sistem file, bukan nol kesalahan data. Ketika korupsi serius ditemukan, itu memutar kembali transaksi, melakukan apa pun yang diperlukan untuk membuat integritas sistem file yang baik. Akibatnya, pembaruan file hilang ketika memutar kembali ke versi file sebelum korupsi, dan karenanya kehilangan data dapat terjadi. Tetapi sistem file Anda bebas dari kesalahan.

Mungkin untuk kesalahan sederhana, ZFS dapat mengembalikan dan menulis ulang data dalam upaya lain, tetapi tampaknya dalam kasus serius perilaku disk yang buruk, ZFS dapat masuk ke catch-22 di mana data tidak dipulihkan dan ditulis. Jika Anda perlu mengumpulkan bukti tentang kesalahan disk, buat itu muncul di layar dan jangan mengandalkan bukti yang akan berada di disk, di mana data berpotensi disetel ulang oleh rollback transaksi ZFS.


Dua hal. Satu, saya tidak begitu mengerti bagaimana ini menjawab pertanyaan; mungkin Anda bisa mengklarifikasi? Dua, jawaban ini tampaknya salah secara faktual. Dalam kata-kata dari salah satu lead tim ZFS asli , "catatan bahwa ZFS end-to-end integritas data tidak memerlukan perangkat keras khusus" (penekanan saya). Jika terjadi crash sistem, Anda dapat kehilangan txg yang saat ini beredar, dan zpool import -Fdapat digunakan jika txg baru-baru ini tidak dapat digunakan, tetapi klaim rollback txg otomatis IMO akan memerlukan kutipan.
CVn

OP bertanya: "Mengapa ZFS tidak melaporkan apa pun tentang masalah baca". Saya menjawab itu. ZFS tidak dapat melaporkan ke file pada disk ketika tidak dapat menulis ke disk. ZFS tidak bisa sempurna ketika kinerja perangkat keras tidak sempurna. Yang bisa dicapai adalah perlindungan terhadap kerusakan sistem file. "Integritas data ujung ke ujung" tergantung pada apa yang dimaksud dengan "data" dan "integritas". Saya percaya itu berarti "tidak ada korupsi", tidak "semua data Anda akan ditulis / dibaca dengan sempurna dalam kondisi apa pun". Ada cara untuk menguji kehilangan di bawah / var, periksa / var / file log untuk jam / hari yang hilang. Saya melihat bahwa.
labradort

(1) Akulah OP. (2) Seperti yang ditunjukkan dalam pertanyaan, vdev adalah konfigurasi mirror. (3) Klaim adalah bahwa sekali data pada ZFS telah membuatnya menjadi penyimpanan persisten, itu akan tetap ada dan dapat dibaca atau operasi I / O akan mengembalikan kesalahan baca. (4) OS dengan jelas mendeteksi masalah I / O, dan baik kernel itu sendiri atau ZFS pulih darinya (karena operasi baca berhasil), namun kesalahan I / O tidak dicatat dalam statistik kumpulan.
CVn

ZFS saya juga merupakan cermin. Tetapi kesalahan firmware dapat memuntahkan sampah sehingga tidak ada disk yang berfungsi dengan baik. Di mana kesalahan dan statistik kumpulan ditulis? Ke media yang buruk. Lihat di file di area / var / log Anda. Lihatlah file-file yang secara konstan ditulis untuk apa pun yang dilakukan server Anda. Jika mengirim, lihat maillog. Jika web, lihat log akses. Kalau tidak, coba pesan. Jika saya benar, akan ada kesenjangan waktu (dalam kasus saya, hari-hari yang hilang) dari file log. Itu adalah bukti bahwa data hilang. Jangan percaya padaku. Jangan mencari kutipan. Lihatlah file-file Anda, dan itu dapat mengkonfirmasi apa yang terjadi.
labradort
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.