আমি এই ধারণাটির মধ্যে ছিলাম যে কোনও জেডএফএস পুল থেকে পড়ার সময় যদি আই / ও ত্রুটি ঘটে থাকে তবে দুটি জিনিস ঘটবে:
- ব্যর্থতাটি পুলের স্তরের দিকে উপরের দিকে প্রচার করে প্রাসঙ্গিক ডিভাইসের READ বা CKSUM পরিসংখ্যানগুলিতে রেকর্ড করা হবে।
- রিডানড্যান্ট ডেটা অনুরোধ করা ব্লকটি পুনর্গঠন করতে, অনুরোধকৃত ব্লককে কলারের কাছে ফিরিয়ে আনতে এবং ডাফ ড্রাইভটি এখনও কার্যকর থাকলে এটিতে ব্লকটি পুনরায় লেখুন, বা
- রিড্যান্ড্যান্ট ডেটা পড়ার ত্রুটির জন্য সংশোধন করার জন্য উপলব্ধ না হলে একটি আই / ও ত্রুটি ফিরে আসবে।
দেখা যাচ্ছে যে আমার আয়না সেটআপের ডিস্কগুলির মধ্যে একটিতে একটি খারাপ ক্ষেত্র বিকাশ হয়েছে। এটি নিজেই উদ্বেগজনক নয়; এ জাতীয় জিনিসগুলি ঘটে থাকে এবং ঠিক সেই কারণেই আমার কাছে অপ্রয়োজনীয়তা রয়েছে (দ্বি-মুখী আয়না, হুবহু হতে)। প্রতিবার যখন আমি পুলটি স্ক্রাব করি বা কোনও নির্দিষ্ট ডিরেক্টরিতে ফাইলগুলি পড়ি (তবে কোন ফাইলটি ঠিক ত্রুটিযুক্ত তা নির্ধারণ করার জন্য আমি এখনও বিরক্ত করিনি), নিম্নলিখিতগুলি ডেমসগে প্রকাশিত হয়, স্পষ্টতই বিভিন্ন টাইমস্ট্যাম্প সহ:
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
এটি দেবিয়ান হুইজি, কার্নেল 3.2.0-4-amd64 # 1 এসএমপি ডেবিয়ান 3.2.63-2 x86_64, জোল 0.6.3 থেকে মোটামুটি আপ টু ডেট। প্যাকেজ সংস্করণগুলি ডিবিয়ান-জেফএস = 7 ~ হুইজি, লিবজফস 2 = 0.6.3-1 ~ হুইজি, জেডএফএস-ডিকিএমএস = 0.6.3-1 ~ হুইজি, জেফএস-ইনিরামফস = 0.6.3-1 ~ হুইজি, জেফসুইটিস = 0.6 .3-1 ~ হুইজি, জেফসনলিনাক্স = 3 ~ হুইজি, লিনাক্স-ইমেজ-এমডি 64 = 3.2 + 46, লিনাক্স-চিত্র -3.2.0-4-এএমডি 64 = 3.2.63-2। আমার জানা একমাত্র প্যাকেজ পিনিং হল জোলের জন্য, যার জন্য আমার রয়েছে (জেডফসনলিনাক্স প্যাকেজ সরবরাহ করে):
Package: *
Pin: release o=archive.zfsonlinux.org
Pin-Priority: 1001
চলমান hdparm -Rড্রাইভ যে রিপোর্ট লেখা-পড়ুন, যাচাই করুন চালু থাকে (এটি Seagate উপর, যাতে বৈশিষ্ট্য আছে এবং আমি একটি অতিরিক্ত নিরাপত্তা জাল হিসাবে এটি ব্যবহার; এর সাথে বাড়তি লেখার লেটেন্সি একটি সমস্যা থেকে আমার ইন্টারেক্টিভ ব্যবহার প্যাটার্ন খুব পড়া হয় না -heavy):
/dev/disk/by-id/ata-ST4000NM0033-9ZM170_XXXXXXXX:
write-read-verify = 2
এমনকি কিছু ভুল আছে এমন পরিষ্কার ইঙ্গিত দিয়েও zpool statusদাবি করেছে যে পুলটিতে কোনও সমস্যা নেই:
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
এই ত্রুটিটি গত বেশ কয়েকটি দিন ধরে লগগুলিতে নিয়মিতভাবে প্রদর্শিত হচ্ছে (২ Oct অক্টোবর থেকে) সুতরাং আমি এটিকে নিছক এক প্রকারের মত লিখতে ভুগছি না। আমি বেশ সংক্ষিপ্ত এসসিটিআরসি টাইমআউট দিয়ে ডিস্কগুলি চালিত করি; 1.5 সেকেন্ড পড়ুন (পড়ার ত্রুটিগুলি থেকে দ্রুত পুনরুদ্ধার করতে), 10 সেকেন্ড লিখুন। আমি নিশ্চিত করেছি যে এই মানগুলি প্রশ্নযুক্ত ড্রাইভে সক্রিয় রয়েছে।
এটিএর ত্রুটি গণনাটি আরোহণের বিষয়টির বিষয়ে স্মার্টডি আমাকে উত্তেজিত রাখে (যা নিজেই একটি ভাল জিনিস!)
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.
প্রশ্নযুক্ত smartctl --attributesড্রাইভে চালনা করলে নিম্নলিখিতটি পাওয়া যায়:
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
সেখানে সাধারণ দিক থেকে সুস্পষ্টরূপে কিছুই নেই। নোট করুন যে এটি একটি এন্টারপ্রাইজ ড্রাইভ, সুতরাং পাঁচ বছরের ওয়্যারেন্টি এবং 24x7 অপারেশনের জন্য রেট দেওয়া হয়েছে (এর অর্থ এটি এখন পর্যন্ত তার বেল্টের অধীনে 10,000 ঘন্টাের তুলনায় কমপক্ষে 40,000 ঘন্টা অপারেশনের জন্য নির্ভরযোগ্য হতে হবে)। সংখ্যার 187 টির মধ্যে 5 নম্বরটি লক্ষ্য করুন রিপোর্ট করেছেন_অনুসংশোধন; সমস্যা যেখানে সেখানে। এছাড়াও প্রতিটি কমপক্ষে 100 এর নিচে মোট কম স্টার্ট_টপ_কাউন্ট এবং পাওয়ার_সাইকেল_কাউন্ট মানগুলি নোট করুন।
আমি মনে করি না যে এটি এই ক্ষেত্রে প্রাসঙ্গিক, তবে হ্যাঁ, সিস্টেমে ইসিসি র্যাম রয়েছে।
পুলের মূল ফাইল সিস্টেমের অ-ডিফল্ট বৈশিষ্ট্যগুলি হ'ল:
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 -
এবং একইভাবে পুল নিজেই :
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
এই তালিকা চালানো দ্বারা প্রাপ্ত করা হয়েছিল {zfs,zpool} get all akita | grep -v default।
এখন প্রশ্নের জন্য:
জেডএফএস কেন পড়ার সমস্যা সম্পর্কে কিছু রিপোর্ট করছে না ? এটি পরিষ্কারভাবে এটি থেকে সুস্থ হয়ে উঠছে।
জেডএফএস কেন স্বয়ংক্রিয়ভাবে ডুফ সেক্টরটি পুনরায় লেখছে না যে ড্রাইভে স্পষ্টভাবে পড়তে সমস্যা হচ্ছে, পরিবর্তে আশা করা যায় যে রিড অনুরোধের পথে স্বয়ংক্রিয় মেরামতের জন্য পর্যাপ্ত অপ্রয়োজনীয়তা রয়েছে?