Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #237483 > unrolled thread
| Started by | Urs Thuermann <urs@isnogud.escape.de> |
|---|---|
| First post | 2021-07-17 14:50 +0200 |
| Last post | 2021-07-19 00:50 +0200 |
| Articles | 14 — 8 participants |
Back to article view | Back to linux.debian.user
RAID-1 and disk I/O Urs Thuermann <urs@isnogud.escape.de> - 2021-07-17 14:50 +0200
Re: RAID-1 and disk I/O Nicholas Geovanis <nickgeovanis@gmail.com> - 2021-07-17 16:40 +0200
Re: RAID-1 and disk I/O Bob Weber <bobrweber@gmail.com> - 2021-07-17 16:50 +0200
Re: RAID-1 and disk I/O Andy Smith <andy@strugglers.net> - 2021-07-17 17:00 +0200
Re: RAID-1 and disk I/O David Christensen <dpchrist@holgerdanske.com> - 2021-07-17 23:10 +0200
Re: RAID-1 and disk I/O David <bouncingcats@gmail.com> - 2021-07-18 03:40 +0200
Re: RAID-1 and disk I/O David Christensen <dpchrist@holgerdanske.com> - 2021-07-18 09:10 +0200
Re: RAID-1 and disk I/O rhkramer@gmail.com - 2021-07-18 13:10 +0200
Re: RAID-1 and disk I/O David <bouncingcats@gmail.com> - 2021-07-18 15:40 +0200
Re: RAID-1 and disk I/O rhkramer@gmail.com - 2021-07-19 01:40 +0200
Re: RAID-1 and disk I/O Reco <recoverym4n@enotuniq.net> - 2021-07-18 11:20 +0200
Re: RAID-1 and disk I/O David Christensen <dpchrist@holgerdanske.com> - 2021-07-18 23:00 +0200
Re: RAID-1 and disk I/O Urs Thuermann <urs@isnogud.escape.de> - 2021-07-18 23:40 +0200
Re: RAID-1 and disk I/O David Christensen <dpchrist@holgerdanske.com> - 2021-07-19 00:50 +0200
| From | Urs Thuermann <urs@isnogud.escape.de> |
|---|---|
| Date | 2021-07-17 14:50 +0200 |
| Subject | RAID-1 and disk I/O |
| Message-ID | <CBRVv-rW-1@gated-at.bofh.it> |
On my server running Debian stretch, the storage setup is as follows:
Two identical SATA disks with 1 partition on each drive spanning the
whole drive, i.e. /dev/sda1 and /dev/sdb1. Then, /dev/sda1 and
/dev/sdb1 form a RAID-1 /dev/md0 with LVM on top of it.
The disk I/O shows very different usage of the two SATA disks:
# iostat | grep -E '^[amDL ]|^sd[ab]'
Linux 5.13.1 (bit) 07/17/21 _x86_64_ (2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
3.78 0.00 2.27 0.86 0.00 93.10
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sdb 4.54 72.16 61.25 54869901 46577068
sda 3.72 35.53 61.25 27014254 46577068
md0 5.53 107.19 57.37 81504323 43624519
The data written to the SATA disks is about 7% = (47 GB - 44 GB) / 44 GB
more than to the RAID device /dev/md0. Is that the expected overhead
for RAID-1 meta data?
But much more noticable is the difference of data reads of the two
disks, i.e. 55 GB and 27 GB, i.e. roughly twice as much data is read
from /dev/sdb compared to /dev/sda. Trying to figure out the reason
for this, dmesg didn't give me anything but I found the following with
smartctl:
------------------------------------------------------------------------------
# diff -U20 <(smartctl -x /dev/sda) <(smartctl -x /dev/sdb)
--- /dev/fd/63 2021-07-17 12:09:00.425352672 +0200
+++ /dev/fd/62 2021-07-17 12:09:00.425352672 +0200
@@ -1,165 +1,164 @@
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-5.13.1] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Seagate Barracuda 7200.14 (AF)
Device Model: ST2000DM001-1ER164
-Serial Number: W4Z171HL
-LU WWN Device Id: 5 000c50 07d3ebd67
+Serial Number: Z4Z2M4T1
+LU WWN Device Id: 5 000c50 07b21e7db
Firmware Version: CC25
User Capacity: 2,000,397,852,160 bytes [2.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 7200 rpm
Form Factor: 3.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2, ACS-3 T13/2161-D revision 3b
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Sat Jul 17 12:09:00 2021 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
AAM feature is: Unavailable
APM level is: 254 (maximum performance)
Rd look-ahead is: Enabled
Write cache is: Enabled
ATA Security is: Disabled, NOT FROZEN [SEC1]
Wt Cache Reorder: Unavailable
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x82) Offline data collection activity
was completed without error.
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: ( 89) seconds.
+data collection: ( 80) 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: ( 1) minutes.
Extended self-test routine
-recommended polling time: ( 213) minutes.
+recommended polling time: ( 211) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
SCT capabilities: (0x1085) SCT Status supported.
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE
- 1 Raw_Read_Error_Rate POSR-- 119 099 006 - 208245592
- 3 Spin_Up_Time PO---- 097 096 000 - 0
- 4 Start_Stop_Count -O--CK 100 100 020 - 71
+ 1 Raw_Read_Error_Rate POSR-- 117 099 006 - 117642848
+ 3 Spin_Up_Time PO---- 096 096 000 - 0
+ 4 Start_Stop_Count -O--CK 100 100 020 - 647
5 Reallocated_Sector_Ct PO--CK 100 100 010 - 0
- 7 Seek_Error_Rate POSR-- 087 060 030 - 471403407
- 9 Power_On_Hours -O--CK 042 042 000 - 51289
+ 7 Seek_Error_Rate POSR-- 086 060 030 - 450781243
+ 9 Power_On_Hours -O--CK 051 051 000 - 43740
10 Spin_Retry_Count PO--C- 100 100 097 - 0
- 12 Power_Cycle_Count -O--CK 100 100 020 - 36
-183 Runtime_Bad_Block -O--CK 093 093 000 - 7
+ 12 Power_Cycle_Count -O--CK 100 100 020 - 29
+183 Runtime_Bad_Block -O--CK 097 097 000 - 3
184 End-to-End_Error -O--CK 100 100 099 - 0
187 Reported_Uncorrect -O--CK 100 100 000 - 0
-188 Command_Timeout -O--CK 100 094 000 - 8 14 17
-189 High_Fly_Writes -O-RCK 098 098 000 - 2
-190 Airflow_Temperature_Cel -O---K 056 049 045 - 44 (Min/Max 43/45)
+188 Command_Timeout -O--CK 100 100 000 - 0 0 0
+189 High_Fly_Writes -O-RCK 097 097 000 - 3
+190 Airflow_Temperature_Cel -O---K 057 050 045 - 43 (Min/Max 42/44)
191 G-Sense_Error_Rate -O--CK 100 100 000 - 0
-192 Power-Off_Retract_Count -O--CK 100 100 000 - 68
-193 Load_Cycle_Count -O--CK 100 100 000 - 1508
-194 Temperature_Celsius -O---K 044 051 000 - 44 (0 17 0 0 0)
+192 Power-Off_Retract_Count -O--CK 100 100 000 - 647
+193 Load_Cycle_Count -O--CK 100 100 000 - 1222
+194 Temperature_Celsius -O---K 043 050 000 - 43 (0 17 0 0 0)
197 Current_Pending_Sector -O--C- 100 100 000 - 0
198 Offline_Uncorrectable ----C- 100 100 000 - 0
-199 UDMA_CRC_Error_Count -OSRCK 200 197 000 - 11058
-240 Head_Flying_Hours ------ 100 253 000 - 51241h+51m+36.964s
-241 Total_LBAs_Written ------ 100 253 000 - 48056776364
-242 Total_LBAs_Read ------ 100 253 000 - 311423095933
+199 UDMA_CRC_Error_Count -OSRCK 200 200 000 - 29
+240 Head_Flying_Hours ------ 100 253 000 - 43708h+01m+21.667s
+241 Total_LBAs_Written ------ 100 253 000 - 28889348871
+242 Total_LBAs_Read ------ 100 253 000 - 329548763597
||||||_ K auto-keep
|||||__ C event count
||||___ R error rate
|||____ S speed/performance
||_____ O updated online
|______ P prefailure warning
General Purpose Log Directory Version 1
SMART Log Directory Version 1 [multi-sector log support]
Address Access R/W Size Description
0x00 GPL,SL R/O 1 Log Directory
0x01 SL R/O 1 Summary SMART error log
0x02 SL R/O 5 Comprehensive SMART error log
0x03 GPL R/O 5 Ext. Comprehensive SMART error log
0x06 SL R/O 1 SMART self-test log
0x07 GPL R/O 1 Extended self-test log
0x09 SL R/W 1 Selective self-test log
0x10 GPL R/O 1 SATA NCQ Queued Error log
0x11 GPL R/O 1 SATA Phy Event Counters log
0x21 GPL R/O 1 Write stream error log
0x22 GPL R/O 1 Read stream error log
0x30 GPL,SL R/O 9 IDENTIFY DEVICE data log
0x80-0x9f GPL,SL R/W 16 Host vendor specific log
0xa1 GPL,SL VS 20 Device vendor specific log
0xa2 GPL VS 4496 Device vendor specific log
0xa8 GPL,SL VS 129 Device vendor specific log
0xa9 GPL,SL VS 1 Device vendor specific log
0xab GPL VS 1 Device vendor specific log
0xb0 GPL VS 5176 Device vendor specific log
0xbe-0xbf GPL VS 65535 Device vendor specific log
0xc0 GPL,SL VS 1 Device vendor specific log
0xc1 GPL,SL VS 10 Device vendor specific log
-0xc3 GPL,SL VS 8 Device vendor specific log
0xe0 GPL,SL R/W 1 SCT Command/Status
0xe1 GPL,SL R/W 1 SCT Data Transfer
SMART Extended Comprehensive Error Log Version: 1 (5 sectors)
No Errors Logged
SMART Extended Self-test Log Version: 1 (1 sectors)
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
-# 1 Short offline Completed without error 00% 21808 -
+# 1 Short offline Completed without error 00% 14254 -
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.
SCT Status Version: 3
SCT Version (vendor specific): 522 (0x020a)
SCT Support Level: 1
Device State: Active (0)
-Current Temperature: 44 Celsius
-Power Cycle Min/Max Temperature: 43/45 Celsius
-Lifetime Min/Max Temperature: 16/51 Celsius
+Current Temperature: 43 Celsius
+Power Cycle Min/Max Temperature: 42/44 Celsius
+Lifetime Min/Max Temperature: 16/50 Celsius
Under/Over Temperature Limit Count: 0/0
SCT Data Table command not supported
SCT Error Recovery Control command not supported
Device Statistics (GP/SMART Log 0x04) not supported
SATA Phy Event Counters (GP Log 0x11)
ID Size Value Description
0x000a 2 8 Device-to-host register FISes sent due to a COMRESET
0x0001 2 0 Command failed due to ICRC error
0x0003 2 0 R_ERR response for device-to-host data FIS
0x0004 2 0 R_ERR response for host-to-device data FIS
0x0006 2 0 R_ERR response for device-to-host non-data FIS
0x0007 2 0 R_ERR response for host-to-device non-data FIS
------------------------------------------------------------------------------
Here, the noticable lines are IMHO
Raw_Read_Error_Rate (208245592 vs. 117642848)
Command_Timeout (8 14 17 vs. 0 0 0)
UDMA_CRC_Error_Count (11058 vs. 29)
Do these numbers indicate a serious problem with my /dev/sda drive?
And is it a disk problem or a transmission problem?
UDMA_CRC_Error_Count sounds like a cable problem for me, right?
BTW, for a year so I had problems with /dev/sda every couple of month,
where the kernel set the drive status in the RAID array to failed. I
could always fix the problem by hot-plugging out the drive, wiggling
the SATA cable, re-inserting and re-adding the drive (without any
impact on the running server). Now, I haven't seen the problem for
quite a while. My suspect is that the cable is still not working very
good, but failures are not often enough to set the drive to "failed"
status.
urs
[toc] | [next] | [standalone]
| From | Nicholas Geovanis <nickgeovanis@gmail.com> |
|---|---|
| Date | 2021-07-17 16:40 +0200 |
| Message-ID | <CBTDX-1zs-3@gated-at.bofh.it> |
| In reply to | #237483 |
[Multipart message — attachments visible in raw view] — view raw
I'm going to echo your final thought there: Replace the SATA cables with 2 NEW ones of the same model. Then see how it goes, meaning rerun the tests you just ran. If possible, try to make the geometries of the cables as similar as you can: roughly same (short?) lengths, roughly as straight and congruent as you are able. Keep in mind that the minor flaws on the drive surfaces are different, each drive from the other. The list of known bad blocks will be different from one drive to the other and that can affect performance of the filesystem built on it. On Sat, Jul 17, 2021, 7:42 AM Urs Thuermann <urs@isnogud.escape.de> wrote: > On my server running Debian stretch, the storage setup is as follows: > Two identical SATA disks with 1 partition on each drive spanning the > whole drive, i.e. /dev/sda1 and /dev/sdb1. Then, /dev/sda1 and > /dev/sdb1 form a RAID-1 /dev/md0 with LVM on top of it. > > The disk I/O shows very different usage of the two SATA disks: > > # iostat | grep -E '^[amDL ]|^sd[ab]' > Linux 5.13.1 (bit) 07/17/21 _x86_64_ (2 CPU) > avg-cpu: %user %nice %system %iowait %steal %idle > 3.78 0.00 2.27 0.86 0.00 93.10 > Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn > sdb 4.54 72.16 61.25 54869901 46577068 > sda 3.72 35.53 61.25 27014254 46577068 > md0 5.53 107.19 57.37 81504323 43624519 > > The data written to the SATA disks is about 7% = (47 GB - 44 GB) / 44 GB > more than to the RAID device /dev/md0. Is that the expected overhead > for RAID-1 meta data? > > But much more noticable is the difference of data reads of the two > disks, i.e. 55 GB and 27 GB, i.e. roughly twice as much data is read > from /dev/sdb compared to /dev/sda. Trying to figure out the reason > for this, dmesg didn't give me anything but I found the following with > smartctl: > > > ------------------------------------------------------------------------------ > # diff -U20 <(smartctl -x /dev/sda) <(smartctl -x /dev/sdb) > --- /dev/fd/63 2021-07-17 12:09:00.425352672 +0200 > +++ /dev/fd/62 2021-07-17 12:09:00.425352672 +0200 > @@ -1,165 +1,164 @@ > smartctl 6.6 2016-05-31 r4324 [x86_64-linux-5.13.1] (local build) > Copyright (C) 2002-16, Bruce Allen, Christian Franke, > www.smartmontools.org > > === START OF INFORMATION SECTION === > Model Family: Seagate Barracuda 7200.14 (AF) > Device Model: ST2000DM001-1ER164 > -Serial Number: W4Z171HL > -LU WWN Device Id: 5 000c50 07d3ebd67 > +Serial Number: Z4Z2M4T1 > +LU WWN Device Id: 5 000c50 07b21e7db > Firmware Version: CC25 > User Capacity: 2,000,397,852,160 bytes [2.00 TB] > Sector Sizes: 512 bytes logical, 4096 bytes physical > Rotation Rate: 7200 rpm > Form Factor: 3.5 inches > Device is: In smartctl database [for details use: -P show] > ATA Version is: ACS-2, ACS-3 T13/2161-D revision 3b > SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s) > Local Time is: Sat Jul 17 12:09:00 2021 CEST > SMART support is: Available - device has SMART capability. > SMART support is: Enabled > AAM feature is: Unavailable > APM level is: 254 (maximum performance) > Rd look-ahead is: Enabled > Write cache is: Enabled > ATA Security is: Disabled, NOT FROZEN [SEC1] > Wt Cache Reorder: Unavailable > > === START OF READ SMART DATA SECTION === > SMART overall-health self-assessment test result: PASSED > > General SMART Values: > Offline data collection status: (0x82) Offline data collection > activity > was completed without error. > 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: ( 89) seconds. > +data collection: ( 80) 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: ( 1) minutes. > Extended self-test routine > -recommended polling time: ( 213) minutes. > +recommended polling time: ( 211) minutes. > Conveyance self-test routine > recommended polling time: ( 2) minutes. > SCT capabilities: (0x1085) SCT Status supported. > > SMART Attributes Data Structure revision number: 10 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE > - 1 Raw_Read_Error_Rate POSR-- 119 099 006 - 208245592 > - 3 Spin_Up_Time PO---- 097 096 000 - 0 > - 4 Start_Stop_Count -O--CK 100 100 020 - 71 > + 1 Raw_Read_Error_Rate POSR-- 117 099 006 - 117642848 > + 3 Spin_Up_Time PO---- 096 096 000 - 0 > + 4 Start_Stop_Count -O--CK 100 100 020 - 647 > 5 Reallocated_Sector_Ct PO--CK 100 100 010 - 0 > - 7 Seek_Error_Rate POSR-- 087 060 030 - 471403407 > - 9 Power_On_Hours -O--CK 042 042 000 - 51289 > + 7 Seek_Error_Rate POSR-- 086 060 030 - 450781243 > + 9 Power_On_Hours -O--CK 051 051 000 - 43740 > 10 Spin_Retry_Count PO--C- 100 100 097 - 0 > - 12 Power_Cycle_Count -O--CK 100 100 020 - 36 > -183 Runtime_Bad_Block -O--CK 093 093 000 - 7 > + 12 Power_Cycle_Count -O--CK 100 100 020 - 29 > +183 Runtime_Bad_Block -O--CK 097 097 000 - 3 > 184 End-to-End_Error -O--CK 100 100 099 - 0 > 187 Reported_Uncorrect -O--CK 100 100 000 - 0 > -188 Command_Timeout -O--CK 100 094 000 - 8 14 17 > -189 High_Fly_Writes -O-RCK 098 098 000 - 2 > -190 Airflow_Temperature_Cel -O---K 056 049 045 - 44 (Min/Max > 43/45) > +188 Command_Timeout -O--CK 100 100 000 - 0 0 0 > +189 High_Fly_Writes -O-RCK 097 097 000 - 3 > +190 Airflow_Temperature_Cel -O---K 057 050 045 - 43 (Min/Max > 42/44) > 191 G-Sense_Error_Rate -O--CK 100 100 000 - 0 > -192 Power-Off_Retract_Count -O--CK 100 100 000 - 68 > -193 Load_Cycle_Count -O--CK 100 100 000 - 1508 > -194 Temperature_Celsius -O---K 044 051 000 - 44 (0 17 0 0 > 0) > +192 Power-Off_Retract_Count -O--CK 100 100 000 - 647 > +193 Load_Cycle_Count -O--CK 100 100 000 - 1222 > +194 Temperature_Celsius -O---K 043 050 000 - 43 (0 17 0 0 > 0) > 197 Current_Pending_Sector -O--C- 100 100 000 - 0 > 198 Offline_Uncorrectable ----C- 100 100 000 - 0 > -199 UDMA_CRC_Error_Count -OSRCK 200 197 000 - 11058 > -240 Head_Flying_Hours ------ 100 253 000 - > 51241h+51m+36.964s > -241 Total_LBAs_Written ------ 100 253 000 - 48056776364 > -242 Total_LBAs_Read ------ 100 253 000 - 311423095933 > +199 UDMA_CRC_Error_Count -OSRCK 200 200 000 - 29 > +240 Head_Flying_Hours ------ 100 253 000 - > 43708h+01m+21.667s > +241 Total_LBAs_Written ------ 100 253 000 - 28889348871 > +242 Total_LBAs_Read ------ 100 253 000 - 329548763597 > ||||||_ K auto-keep > |||||__ C event count > ||||___ R error rate > |||____ S speed/performance > ||_____ O updated online > |______ P prefailure warning > > General Purpose Log Directory Version 1 > SMART Log Directory Version 1 [multi-sector log support] > Address Access R/W Size Description > 0x00 GPL,SL R/O 1 Log Directory > 0x01 SL R/O 1 Summary SMART error log > 0x02 SL R/O 5 Comprehensive SMART error log > 0x03 GPL R/O 5 Ext. Comprehensive SMART error log > 0x06 SL R/O 1 SMART self-test log > 0x07 GPL R/O 1 Extended self-test log > 0x09 SL R/W 1 Selective self-test log > 0x10 GPL R/O 1 SATA NCQ Queued Error log > 0x11 GPL R/O 1 SATA Phy Event Counters log > 0x21 GPL R/O 1 Write stream error log > 0x22 GPL R/O 1 Read stream error log > 0x30 GPL,SL R/O 9 IDENTIFY DEVICE data log > 0x80-0x9f GPL,SL R/W 16 Host vendor specific log > 0xa1 GPL,SL VS 20 Device vendor specific log > 0xa2 GPL VS 4496 Device vendor specific log > 0xa8 GPL,SL VS 129 Device vendor specific log > 0xa9 GPL,SL VS 1 Device vendor specific log > 0xab GPL VS 1 Device vendor specific log > 0xb0 GPL VS 5176 Device vendor specific log > 0xbe-0xbf GPL VS 65535 Device vendor specific log > 0xc0 GPL,SL VS 1 Device vendor specific log > 0xc1 GPL,SL VS 10 Device vendor specific log > -0xc3 GPL,SL VS 8 Device vendor specific log > 0xe0 GPL,SL R/W 1 SCT Command/Status > 0xe1 GPL,SL R/W 1 SCT Data Transfer > > SMART Extended Comprehensive Error Log Version: 1 (5 sectors) > No Errors Logged > > SMART Extended Self-test Log Version: 1 (1 sectors) > Num Test_Description Status Remaining > LifeTime(hours) LBA_of_first_error > -# 1 Short offline Completed without error 00% 21808 > - > +# 1 Short offline Completed without error 00% 14254 > - > > 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. > > SCT Status Version: 3 > SCT Version (vendor specific): 522 (0x020a) > SCT Support Level: 1 > Device State: Active (0) > -Current Temperature: 44 Celsius > -Power Cycle Min/Max Temperature: 43/45 Celsius > -Lifetime Min/Max Temperature: 16/51 Celsius > +Current Temperature: 43 Celsius > +Power Cycle Min/Max Temperature: 42/44 Celsius > +Lifetime Min/Max Temperature: 16/50 Celsius > Under/Over Temperature Limit Count: 0/0 > > SCT Data Table command not supported > > SCT Error Recovery Control command not supported > > Device Statistics (GP/SMART Log 0x04) not supported > > SATA Phy Event Counters (GP Log 0x11) > ID Size Value Description > 0x000a 2 8 Device-to-host register FISes sent due to a > COMRESET > 0x0001 2 0 Command failed due to ICRC error > 0x0003 2 0 R_ERR response for device-to-host data FIS > 0x0004 2 0 R_ERR response for host-to-device data FIS > 0x0006 2 0 R_ERR response for device-to-host non-data FIS > 0x0007 2 0 R_ERR response for host-to-device non-data FIS > > ------------------------------------------------------------------------------ > > > Here, the noticable lines are IMHO > > Raw_Read_Error_Rate (208245592 vs. 117642848) > Command_Timeout (8 14 17 vs. 0 0 0) > UDMA_CRC_Error_Count (11058 vs. 29) > > Do these numbers indicate a serious problem with my /dev/sda drive? > And is it a disk problem or a transmission problem? > UDMA_CRC_Error_Count sounds like a cable problem for me, right? > > BTW, for a year so I had problems with /dev/sda every couple of month, > where the kernel set the drive status in the RAID array to failed. I > could always fix the problem by hot-plugging out the drive, wiggling > the SATA cable, re-inserting and re-adding the drive (without any > impact on the running server). Now, I haven't seen the problem for > quite a while. My suspect is that the cable is still not working very > good, but failures are not often enough to set the drive to "failed" > status. > > urs > >
[toc] | [prev] | [next] | [standalone]
| From | Bob Weber <bobrweber@gmail.com> |
|---|---|
| Date | 2021-07-17 16:50 +0200 |
| Message-ID | <CBTND-1CN-1@gated-at.bofh.it> |
| In reply to | #237483 |
[Multipart message — attachments visible in raw view] — view raw
On 7/17/21 08:34, Urs Thuermann wrote: > Here, the noticable lines are IMHO > > Raw_Read_Error_Rate (208245592 vs. 117642848) > Command_Timeout (8 14 17 vs. 0 0 0) > UDMA_CRC_Error_Count (11058 vs. 29) > > Do these numbers indicate a serious problem with my /dev/sda drive? > And is it a disk problem or a transmission problem? > UDMA_CRC_Error_Count sounds like a cable problem for me, right? > > BTW, for a year so I had problems with /dev/sda every couple of month, > where the kernel set the drive status in the RAID array to failed. I > could always fix the problem by hot-plugging out the drive, wiggling > the SATA cable, re-inserting and re-adding the drive (without any > impact on the running server). Now, I haven't seen the problem for > quite a while. My suspect is that the cable is still not working very > good, but failures are not often enough to set the drive to "failed" > status. > > urs > I switched from Seagate to WD Red years ago since I couldn't get them to last more than a year or so. I have one WD that is 6.87 years old with no errors. Well past the 5 year life expectancy. In recent years WD has pulled a marketing controversy on their Red drives. See: https://arstechnica.com/gadgets/2020/06/western-digital-adds-red-plus-branding-for-non-smr-hard-drives/ So be careful to get the Pro version if you decide to try WD. I use the WD4003FFBX (4T) drives (Raid 1) and have them at 2.8 years running 24/7 with no problems. If you value your data get another drive NOW .. they are already 5 and 5.8 years old! Add it to the array and let it settle in (sync) and see what happens. I hope your existing array can hold together long enough to add a 3rd drive. I would have replaced those drives long ago from all the errors reported. You might want to get new cables also since you have had problems in the past. I also run self tests weekly to make sure the drives are ok. I run smartctl -a daily also. I also run backuppc on a separate server to get backups of important data. There are some programs in /usr/share/mdadm that can check an array but I would wait until you have a new drive added to the array before testing the array. Here is the warning that comes with another script I found: ---------------------------------------- DATA LOSS MAY HAVE OCCURRED. This condition may have been caused by one of more of the following events: . A LEGITIMATE write to a memory mapped file or swap partition backed by a RAID1 (and only a RAID1) device - see the md(4) man page for details. . A power failure when the array was being written-to. Data corruption by a hard disk drive, drive controller, cable etc. . A kernel bug in the md or storage subsystems etc. . An array being forcibly created in an inconsistent state using --assume-clean This count is updated when the md subsystem carries out a 'check' or 'repair' action. In the case of 'repair' it reflects the number of mismatched blocks prior to carrying out the repair. Once you have fixed the error, carry out a 'check' action to reset the count to zero. See the md (section 4) manual page, and the following URL for details: https://raid.wiki.kernel.org/index.php/Linux_Raid#Frequently_Asked_Questions_-_FAQ -------------------------- The problem is that if a miss count occurs then which drive (Raid 1) is correct! I also run programs like debsums to check programs after an update so I know there is no bit rot in important programs as explained above. Hope this helps. -- *...Bob*
[toc] | [prev] | [next] | [standalone]
| From | Andy Smith <andy@strugglers.net> |
|---|---|
| Date | 2021-07-17 17:00 +0200 |
| Message-ID | <CBTXj-1FR-1@gated-at.bofh.it> |
| In reply to | #237483 |
Hi Urs, Your plan to change the SATA cable seems wise - your various error rates are higher than I have normally seen. Also worth bearing in mind that Linux MD RAID 1 will satisfy all read IO for a given operation from one device in the mirror. If you have processes that do occasional big reads then by chance those can end up being served by the same device leading to a big disparity in per-device LBAs read. You can do RAID-10 (even on 2 or 3 devices) which will stripe data at the chunk size resulting in even a single read operation being striped across multiple devices, though overall this may not be more performant than RAID-1, especially if your devices were non-rotational. You would have to measure. I don't know about the write overhead you are seeing. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2021-07-17 23:10 +0200 |
| Message-ID | <CBZJn-5q8-5@gated-at.bofh.it> |
| In reply to | #237483 |
On 7/17/21 5:34 AM, Urs Thuermann wrote: > On my server running Debian stretch, You should consider upgrading to Debian 10 -- more people run that and you will get better support. I migrated to FreeBSD. > the storage setup is as follows: > Two identical SATA disks with 1 partition on each drive spanning the > whole drive, i.e. /dev/sda1 and /dev/sdb1. Then, /dev/sda1 and > /dev/sdb1 form a RAID-1 /dev/md0 with LVM on top of it. ext4? That lacks integrity checking. btrfs? That has integrity checking, but requires periodic balancing. I use ZFS. That has integrity checking. It is wise to do periodic scrubs to check for problems. Are both your operating system and your data on this array? I always use a single, small solid-state device for the system drive, configure my hardware so that it is /dev/sda, and use separate drive(s) for data (/dev/sdb, /dev/sdc, etc.). Separating these concerns simplifies system administration and disaster preparedness/ recovery. > The disk I/O shows very different usage of the two SATA disks: > > # iostat | grep -E '^[amDL ]|^sd[ab]' > Linux 5.13.1 (bit) 07/17/21 _x86_64_ (2 CPU) > avg-cpu: %user %nice %system %iowait %steal %idle > 3.78 0.00 2.27 0.86 0.00 93.10 > Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn > sdb 4.54 72.16 61.25 54869901 46577068 > sda 3.72 35.53 61.25 27014254 46577068 > md0 5.53 107.19 57.37 81504323 43624519 > > The data written to the SATA disks is about 7% = (47 GB - 44 GB) / 44 GB > more than to the RAID device /dev/md0. Is that the expected overhead > for RAID-1 meta data? > > But much more noticable is the difference of data reads of the two > disks, i.e. 55 GB and 27 GB, i.e. roughly twice as much data is read > from /dev/sdb compared to /dev/sda. Trying to figure out the reason > for this, dmesg didn't give me anything Getting meaningful information from system monitoring tools is non-trivial. Perhaps 'iostat 600' concurrent with a run of bonnie++. Or, 'iostat 3600 24' during normal operations. Or, 'iostat' dumped to a time-stamped output file run once an hour by a cron job. Beware of using multiple system monitoring tools at the same time -- they may access the same kernel data structures and step on each other. > but I found the following with > smartctl: > > ------------------------------------------------------------------------------ > # diff -U20 <(smartctl -x /dev/sda) <(smartctl -x /dev/sdb) Why limit unified context to 20 lines? You may be missing information (I have not counted the differences, below). I suggest '-U' alone. > --- /dev/fd/63 2021-07-17 12:09:00.425352672 +0200 > +++ /dev/fd/62 2021-07-17 12:09:00.425352672 +0200 > @@ -1,165 +1,164 @@ > smartctl 6.6 2016-05-31 r4324 [x86_64-linux-5.13.1] (local build) > Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org > > === START OF INFORMATION SECTION === > Model Family: Seagate Barracuda 7200.14 (AF) I burned up both old desktop drives and new enterprise drives when I put them into a server (Samba, CVS) for my SOHO network and ran them 24x7. As my arrays had only one redundant drive (e.g. two drives in RAID1, three drives in RAID5), I had the terrorifying realization that I was at risk of losing everything when a drive failed and I had not replaced it yet. I upgraded to all enterprise drives, bought a spare enterprise drive and put it on the shelf, built another server, replicate periodically to the second server, and replicate periodically to tray-mounted old desktop drives used like backup tapes (and rotated on/off site). I should probably put the spare drive into the live server and set it up as a hot spare. > Device Model: ST2000DM001-1ER164 > -Serial Number: W4Z171HL > -LU WWN Device Id: 5 000c50 07d3ebd67 > +Serial Number: Z4Z2M4T1 > +LU WWN Device Id: 5 000c50 07b21e7db > Firmware Version: CC25 > User Capacity: 2,000,397,852,160 bytes [2.00 TB] > Sector Sizes: 512 bytes logical, 4096 bytes physical > Rotation Rate: 7200 rpm > Form Factor: 3.5 inches > Device is: In smartctl database [for details use: -P show] > ATA Version is: ACS-2, ACS-3 T13/2161-D revision 3b > SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s) You have a SATA transfer speed mismatch -- 6.0 Gbps drives running at 3.0 Gbps. If your ports are 3 Gbps, fine. If your ports are 6 Gbps, you have bad ports, cables, racks, docks, trays, etc.. > Local Time is: Sat Jul 17 12:09:00 2021 CEST > SMART support is: Available - device has SMART capability. > SMART support is: Enabled > AAM feature is: Unavailable > APM level is: 254 (maximum performance) > Rd look-ahead is: Enabled > Write cache is: Enabled > ATA Security is: Disabled, NOT FROZEN [SEC1] > Wt Cache Reorder: Unavailable > > === START OF READ SMART DATA SECTION === > SMART overall-health self-assessment test result: PASSED > > General SMART Values: > Offline data collection status: (0x82) Offline data collection activity > was completed without error. > 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: ( 89) seconds. > +data collection: ( 80) 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: ( 1) minutes. > Extended self-test routine > -recommended polling time: ( 213) minutes. > +recommended polling time: ( 211) minutes. > Conveyance self-test routine > recommended polling time: ( 2) minutes. > SCT capabilities: (0x1085) SCT Status supported. > > SMART Attributes Data Structure revision number: 10 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE > - 1 Raw_Read_Error_Rate POSR-- 119 099 006 - 208245592 > - 3 Spin_Up_Time PO---- 097 096 000 - 0 > - 4 Start_Stop_Count -O--CK 100 100 020 - 71 > + 1 Raw_Read_Error_Rate POSR-- 117 099 006 - 117642848 > + 3 Spin_Up_Time PO---- 096 096 000 - 0 > + 4 Start_Stop_Count -O--CK 100 100 020 - 647 > 5 Reallocated_Sector_Ct PO--CK 100 100 010 - 0 > - 7 Seek_Error_Rate POSR-- 087 060 030 - 471403407 > - 9 Power_On_Hours -O--CK 042 042 000 - 51289 > + 7 Seek_Error_Rate POSR-- 086 060 030 - 450781243 > + 9 Power_On_Hours -O--CK 051 051 000 - 43740 Seek_Error_Rate indicates those drives have seen better days, but are doing their job. Power_On_Hours indicates those drives have seen lots of use. > 10 Spin_Retry_Count PO--C- 100 100 097 - 0 > - 12 Power_Cycle_Count -O--CK 100 100 020 - 36 > -183 Runtime_Bad_Block -O--CK 093 093 000 - 7 > + 12 Power_Cycle_Count -O--CK 100 100 020 - 29 > +183 Runtime_Bad_Block -O--CK 097 097 000 - 3 Power_Cycle_Count indicates that the machine runs 24x7 for long periods without rebooting. Runtime_Bad_Block looks acceptable. > 184 End-to-End_Error -O--CK 100 100 099 - 0 > 187 Reported_Uncorrect -O--CK 100 100 000 - 0 End-to-End_Error and Reported_Uncorrect look perfect. The drives should not have corrupted or lost any data (other hardware and/or events may have). > -188 Command_Timeout -O--CK 100 094 000 - 8 14 17 > -189 High_Fly_Writes -O-RCK 098 098 000 - 2 > -190 Airflow_Temperature_Cel -O---K 056 049 045 - 44 (Min/Max 43/45) > +188 Command_Timeout -O--CK 100 100 000 - 0 0 0 > +189 High_Fly_Writes -O-RCK 097 097 000 - 3 > +190 Airflow_Temperature_Cel -O---K 057 050 045 - 43 (Min/Max 42/44) > 191 G-Sense_Error_Rate -O--CK 100 100 000 - 0 > -192 Power-Off_Retract_Count -O--CK 100 100 000 - 68 > -193 Load_Cycle_Count -O--CK 100 100 000 - 1508 > -194 Temperature_Celsius -O---K 044 051 000 - 44 (0 17 0 0 0) > +192 Power-Off_Retract_Count -O--CK 100 100 000 - 647 > +193 Load_Cycle_Count -O--CK 100 100 000 - 1222 > +194 Temperature_Celsius -O---K 043 050 000 - 43 (0 17 0 0 0) Airflow_Temperature_Cel and Temperature_Celsius are higher than I like. I suggest that you dress cables, add fans, etc., to improve cooling. > 197 Current_Pending_Sector -O--C- 100 100 000 - 0 > 198 Offline_Uncorrectable ----C- 100 100 000 - 0 > -199 UDMA_CRC_Error_Count -OSRCK 200 197 000 - 11058 > -240 Head_Flying_Hours ------ 100 253 000 - 51241h+51m+36.964s > -241 Total_LBAs_Written ------ 100 253 000 - 48056776364 > -242 Total_LBAs_Read ------ 100 253 000 - 311423095933 > +199 UDMA_CRC_Error_Count -OSRCK 200 200 000 - 29 > +240 Head_Flying_Hours ------ 100 253 000 - 43708h+01m+21.667s > +241 Total_LBAs_Written ------ 100 253 000 - 28889348871 > +242 Total_LBAs_Read ------ 100 253 000 - 329548763597 > ||||||_ K auto-keep > |||||__ C event count > ||||___ R error rate > |||____ S speed/performance > ||_____ O updated online > |______ P prefailure warning UDMA_CRC_Error_Count for /dev/sda looks worrisome, both compared to /dev/sdb and compared to reports for my drives. Total_LBAs_Written for /dev/sda is almost double that of /dev/sdb. Where those drives both new when put into RAID1? > General Purpose Log Directory Version 1 > SMART Log Directory Version 1 [multi-sector log support] > Address Access R/W Size Description > 0x00 GPL,SL R/O 1 Log Directory > 0x01 SL R/O 1 Summary SMART error log > 0x02 SL R/O 5 Comprehensive SMART error log > 0x03 GPL R/O 5 Ext. Comprehensive SMART error log > 0x06 SL R/O 1 SMART self-test log > 0x07 GPL R/O 1 Extended self-test log > 0x09 SL R/W 1 Selective self-test log > 0x10 GPL R/O 1 SATA NCQ Queued Error log > 0x11 GPL R/O 1 SATA Phy Event Counters log > 0x21 GPL R/O 1 Write stream error log > 0x22 GPL R/O 1 Read stream error log > 0x30 GPL,SL R/O 9 IDENTIFY DEVICE data log > 0x80-0x9f GPL,SL R/W 16 Host vendor specific log > 0xa1 GPL,SL VS 20 Device vendor specific log > 0xa2 GPL VS 4496 Device vendor specific log > 0xa8 GPL,SL VS 129 Device vendor specific log > 0xa9 GPL,SL VS 1 Device vendor specific log > 0xab GPL VS 1 Device vendor specific log > 0xb0 GPL VS 5176 Device vendor specific log > 0xbe-0xbf GPL VS 65535 Device vendor specific log > 0xc0 GPL,SL VS 1 Device vendor specific log > 0xc1 GPL,SL VS 10 Device vendor specific log > -0xc3 GPL,SL VS 8 Device vendor specific log > 0xe0 GPL,SL R/W 1 SCT Command/Status > 0xe1 GPL,SL R/W 1 SCT Data Transfer > > SMART Extended Comprehensive Error Log Version: 1 (5 sectors) > No Errors Logged > > SMART Extended Self-test Log Version: 1 (1 sectors) > Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error > -# 1 Short offline Completed without error 00% 21808 - > +# 1 Short offline Completed without error 00% 14254 - LifeTime for /dev/sda is ~50% higher than /dev/sdb. So, those drives were not both new when put into RAID1? > 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. > > SCT Status Version: 3 > SCT Version (vendor specific): 522 (0x020a) > SCT Support Level: 1 > Device State: Active (0) > -Current Temperature: 44 Celsius > -Power Cycle Min/Max Temperature: 43/45 Celsius > -Lifetime Min/Max Temperature: 16/51 Celsius > +Current Temperature: 43 Celsius > +Power Cycle Min/Max Temperature: 42/44 Celsius > +Lifetime Min/Max Temperature: 16/50 Celsius > Under/Over Temperature Limit Count: 0/0 > > SCT Data Table command not supported > > SCT Error Recovery Control command not supported > > Device Statistics (GP/SMART Log 0x04) not supported > > SATA Phy Event Counters (GP Log 0x11) > ID Size Value Description > 0x000a 2 8 Device-to-host register FISes sent due to a COMRESET > 0x0001 2 0 Command failed due to ICRC error > 0x0003 2 0 R_ERR response for device-to-host data FIS > 0x0004 2 0 R_ERR response for host-to-device data FIS > 0x0006 2 0 R_ERR response for device-to-host non-data FIS > 0x0007 2 0 R_ERR response for host-to-device non-data FIS > ------------------------------------------------------------------------------ > > > Here, the noticable lines are IMHO > > Raw_Read_Error_Rate (208245592 vs. 117642848) The smartctl(8) RAW_VALUE column is tough to read. Sometimes it looks like an integer. Other times, it looks like a bitmap or big-endian/ little-endian mix-up. The VALUE column is easier. Both 119 and 117 are greater than 100, so I would not worry. > Command_Timeout (8 14 17 vs. 0 0 0) I do not know how to read those numbers. /dev/sda has non-zero values and /dev/sdb has zero values. This supports a theory of communications problems for /dev/sda. > UDMA_CRC_Error_Count (11058 vs. 29) Agreed. > Do these numbers indicate a serious problem with my /dev/sda drive? I'd say "problem" at this point, but not yet "serious". Run reports regularly and watch for growth of problematic statistics -- Raw_Read_Error_Rate, Seek_Error_Rate, Command_Timeout, UDMA_CRC_Error_Count, etc.. > And is it a disk problem or a transmission problem? > UDMA_CRC_Error_Count sounds like a cable problem for me, right? A/B testing (swap the SATA cables at the drives) and periodic testing/ tracking over an extended period with everything else known good (racks, cables, ports, HBA's, etc.) could tell you if there is a drive problem. > BTW, for a year so I had problems with /dev/sda every couple of month, > where the kernel set the drive status in the RAID array to failed. I > could always fix the problem by hot-plugging out the drive, wiggling > the SATA cable, re-inserting and re-adding the drive (without any > impact on the running server). I replaced all of my SATA I/II/III cables in all of my computers about a year ago with Cable Matters black 6G cables with locking straight and/or 90 degree connectors. Life got much better. > Now, I haven't seen the problem for > quite a while. My suspect is that the cable is still not working very > good, but failures are not often enough to set the drive to "failed" > status. I try to run drive diagnostics on a monthly basis and save the reports in a version control system. The data is available if/when I put in the effort to analyze it. (There may be FOSS to automate one or more of these chores.) David
[toc] | [prev] | [next] | [standalone]
| From | David <bouncingcats@gmail.com> |
|---|---|
| Date | 2021-07-18 03:40 +0200 |
| Message-ID | <CC3WF-88w-1@gated-at.bofh.it> |
| In reply to | #237493 |
On Sun, 18 Jul 2021 at 07:03, David Christensen <dpchrist@holgerdanske.com> wrote: > On 7/17/21 5:34 AM, Urs Thuermann wrote: > > On my server running Debian stretch, > > the storage setup is as follows: > > Two identical SATA disks with 1 partition on each drive spanning the > > whole drive, i.e. /dev/sda1 and /dev/sdb1. Then, /dev/sda1 and > > /dev/sdb1 form a RAID-1 /dev/md0 with LVM on top of it. > > ------------------------------------------------------------------------------ > > # diff -U20 <(smartctl -x /dev/sda) <(smartctl -x /dev/sdb) > > - 9 Power_On_Hours -O--CK 042 042 000 - 51289 > > + 9 Power_On_Hours -O--CK 051 051 000 - 43740 > > SMART Extended Self-test Log Version: 1 (1 sectors) > > Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error > > -# 1 Short offline Completed without error 00% 21808 - > > +# 1 Short offline Completed without error 00% 14254 - sda was last self-tested at 21808 hours and is now at 51289. sdb was last self-tested at 14254 hours and is now at 43740. And those were short (a couple of minutes) self-tests only. So these drives have apparently only ever run one short self-test. I am a home user, and I run long self-tests regularly using # smartctl -t long <device> In my opinion these drives are due for a long self-test. I have no idea if this will add any useful information, but there's an obvious way to find out :) A bit more info on self-tests: https://serverfault.com/questions/732423/what-does-smart-testing-do-and-how-does-it-work The 'smartctl' manpage explains how to run and abort self-tests. It also says that a running test can degrade the performance of the drive.
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2021-07-18 09:10 +0200 |
| Message-ID | <CC961-3aX-3@gated-at.bofh.it> |
| In reply to | #237494 |
On 7/17/21 6:30 PM, David wrote: > On Sun, 18 Jul 2021 at 07:03, David Christensen > <dpchrist@holgerdanske.com> wrote: >> On 7/17/21 5:34 AM, Urs Thuermann wrote: > >>> On my server running Debian stretch, >>> the storage setup is as follows: >>> Two identical SATA disks with 1 partition on each drive spanning the >>> whole drive, i.e. /dev/sda1 and /dev/sdb1. Then, /dev/sda1 and >>> /dev/sdb1 form a RAID-1 /dev/md0 with LVM on top of it. > >>> ------------------------------------------------------------------------------ >>> # diff -U20 <(smartctl -x /dev/sda) <(smartctl -x /dev/sdb) > >>> - 9 Power_On_Hours -O--CK 042 042 000 - 51289 >>> + 9 Power_On_Hours -O--CK 051 051 000 - 43740 > >>> SMART Extended Self-test Log Version: 1 (1 sectors) >>> Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error >>> -# 1 Short offline Completed without error 00% 21808 - >>> +# 1 Short offline Completed without error 00% 14254 - > > sda was last self-tested at 21808 hours and is now at 51289. > sdb was last self-tested at 14254 hours and is now at 43740. > And those were short (a couple of minutes) self-tests only. > So these drives have apparently only ever run one short self-test. Thank you for the clarification. :-) David
[toc] | [prev] | [next] | [standalone]
| From | rhkramer@gmail.com |
|---|---|
| Date | 2021-07-18 13:10 +0200 |
| Message-ID | <CCcQi-5DK-1@gated-at.bofh.it> |
| In reply to | #237494 |
On Saturday, July 17, 2021 09:30:56 PM David wrote: > The 'smartctl' manpage explains how to run and abort self-tests. > It also says that a running test can degrade the performance of the drive. Interesting -- not surprising, makes sense, but something (for me, at least) to keep in mind -- probably not a good idea to run on an old drive that hasn't been backed up.
[toc] | [prev] | [next] | [standalone]
| From | David <bouncingcats@gmail.com> |
|---|---|
| Date | 2021-07-18 15:40 +0200 |
| Message-ID | <CCfbs-6We-9@gated-at.bofh.it> |
| In reply to | #237500 |
On Sun, 18 Jul 2021 at 21:08, <rhkramer@gmail.com> wrote: > On Saturday, July 17, 2021 09:30:56 PM David wrote: > > The 'smartctl' manpage explains how to run and abort self-tests. > > It also says that a running test can degrade the performance of the drive. > Interesting -- not surprising, makes sense, but something (for me, at least) > to keep in mind -- probably not a good idea to run on an old drive that hasn't > been backed up. Sorry if my language was unclear. If you read the manpage context, it's explaining that drives can be tested without taking them out of service. So performance is only "degraded" while the test is running, compared to normal operation, because the drive is also busy testing itself. It doesn't mean permanent degradation.
[toc] | [prev] | [next] | [standalone]
| From | rhkramer@gmail.com |
|---|---|
| Date | 2021-07-19 01:40 +0200 |
| Message-ID | <CCoy5-4gX-1@gated-at.bofh.it> |
| In reply to | #237501 |
On Sunday, July 18, 2021 09:37:53 AM David wrote: > On Sun, 18 Jul 2021 at 21:08, <rhkramer@gmail.com> wrote: > > Interesting -- not surprising, makes sense, but something (for me, at > > least) to keep in mind -- probably not a good idea to run on an old > > drive that hasn't been backed up. > > Sorry if my language was unclear. If you read the manpage context, it's > explaining that drives can be tested without taking them out of service. > So performance is only "degraded" while the test is running, compared > to normal operation, because the drive is also busy testing itself. > It doesn't mean permanent degradation. Ahh, ok -- thanks for the clarification!
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2021-07-18 11:20 +0200 |
| Message-ID | <CCb7Q-4vG-3@gated-at.bofh.it> |
| In reply to | #237493 |
Hi. On Sat, Jul 17, 2021 at 02:03:15PM -0700, David Christensen wrote: > > But much more noticable is the difference of data reads of the two > > disks, i.e. 55 GB and 27 GB, i.e. roughly twice as much data is read > > from /dev/sdb compared to /dev/sda. Trying to figure out the reason > > for this, dmesg didn't give me anything > > Getting meaningful information from system monitoring tools is > non-trivial. Perhaps 'iostat 600' concurrent with a run of bonnie++. > Or, 'iostat 3600 24' during normal operations. Or, 'iostat' dumped to > a time-stamped output file run once an hour by a cron job. iostat belongs to sysstat package. sysstat provides sar, which, by default, gathers every detail of the host resource utilization and a little more once per 10 minutes. There's little need for the kludges you're describing for one can simply invoke "sar -pd -f /var/log/sysstat/sa...". Reco
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2021-07-18 23:00 +0200 |
| Message-ID | <CCm3g-2Dt-11@gated-at.bofh.it> |
| In reply to | #237499 |
On 7/18/21 2:16 AM, Reco wrote: > Hi. > > On Sat, Jul 17, 2021 at 02:03:15PM -0700, David Christensen wrote: >>> But much more noticable is the difference of data reads of the two >>> disks, i.e. 55 GB and 27 GB, i.e. roughly twice as much data is read >>> from /dev/sdb compared to /dev/sda. Trying to figure out the reason >>> for this, dmesg didn't give me anything >> >> Getting meaningful information from system monitoring tools is >> non-trivial. Perhaps 'iostat 600' concurrent with a run of bonnie++. >> Or, 'iostat 3600 24' during normal operations. Or, 'iostat' dumped to >> a time-stamped output file run once an hour by a cron job. > > iostat belongs to sysstat package. > sysstat provides sar, which, by default, gathers every detail of the > host resource utilization and a little more once per 10 minutes. > > There's little need for the kludges you're describing for one can simply > invoke "sar -pd -f /var/log/sysstat/sa...". > > Reco Yes, sar(1) looks useful. :-) David
[toc] | [prev] | [next] | [standalone]
| From | Urs Thuermann <urs@isnogud.escape.de> |
|---|---|
| Date | 2021-07-18 23:40 +0200 |
| Message-ID | <CCmFY-34Q-3@gated-at.bofh.it> |
| In reply to | #237493 |
David Christensen <dpchrist@holgerdanske.com> writes:
> You should consider upgrading to Debian 10 -- more people run that and
> you will get better support.
It's on my TODO list. As well as upgrading the very old hardware.
Currently, it's a Gigabyte P35-DS3L with an Intel Core2Duo E8400 CPU
and 8 GB RAM. It's only my private home server and performance is
still sufficient but I hope to reduce power consumption considerably.
> > the storage setup is as follows:
> > Two identical SATA disks with 1 partition on each drive spanning the
> > whole drive, i.e. /dev/sda1 and /dev/sdb1. Then, /dev/sda1 and
> > /dev/sdb1 form a RAID-1 /dev/md0 with LVM on top of it.
>
>
> ext4? That lacks integrity checking.
>
>
> btrfs? That has integrity checking, but requires periodic balancing.
Mostly ext4 for / /var /var/spool/news /usr /usr/local and /home file
systems. The /usr/src file system is btrfs and some test file systems
also. There are also 4 VMs, FreeBSD and NetBSD with their partitions
and slices and ufs file systems, one Linux VM with ext4 and one very
old Linux VM (kernel 2.4) with its own LVM in two LVs and 10 ext3 file
systems.
> Are both your operating system and your data on this array? I always
> use a single, small solid-state device for the system drive, configure
> my hardware so that it is /dev/sda, and use separate drive(s) for data
> (/dev/sdb, /dev/sdc, etc.). Separating these concerns simplifies
> system administration and disaster preparedness/ recovery.
Yes, everything is in the LVs on /dev/md0. Except for some external
USB hard drives for backup (4 TB) and some other seldomly used stuff
(e.g. NTFS drive with some old data of my wife's laptop, I cannot
persuade her to use Linux).
> > but I found the following with
> > smartctl:
> > ------------------------------------------------------------------------------
> > # diff -U20 <(smartctl -x /dev/sda) <(smartctl -x /dev/sdb)
>
>
> Why limit unified context to 20 lines? You may be missing information
> (I have not counted the differences, below). I suggest '-U' alone.
20 lines are just enough to get all. You can see this because there
are less than 20 context lines at the beginning and end of the diff
and only one hunk. GNU diff doesn't allow -U without a line count.
> You have a SATA transfer speed mismatch -- 6.0 Gbps drives running at
> 3.0 Gbps. If your ports are 3 Gbps, fine. If your ports are 6 Gbps,
> you have bad ports, cables, racks, docks, trays, etc..
Yes, the old Gigabyte mainboard has only 3 Gbps ports. I wasn't aware
of this but have just looked up the specs.
> Seek_Error_Rate indicates those drives have seen better days, but are
> doing their job.
>
>
> Power_On_Hours indicates those drives have seen lots of use.
> Power_Cycle_Count indicates that the machine runs 24x7 for long
> periods without rebooting.
Yes, the server runs 24/7 except for kernel updates, and a power
outage 2 weeks ago (my UPS batteries also need replacement... )-:
And the server is about 8 years old, initially with only 1 hard drive
which crashed while my backup was too small to hold everything. This
meant a lot of work (and quite some money) to get everything running
again and to recover data which wasn't in the backup.
This was almost 6 years ago and I then bought 2 Seagate Barracuda
drives for RAID-1 and a larger backup drive. One of the two Seagate
drives is still running and is /dev/sda. The other drive /dev/sdb
crashed after only 9.5 months of operation and I got it replaced by
the dealer. This was when I loved my decision to setup RAID-1. With
no downtime I pulled the failed drive, returned it to the dealer, ran
the system a week or two with only one drive, got the replacement
drive from the dealer hot-plugged it in, synced, and was happy :-)
Only short time after this I also bought a 3.5" removable mounting
frame for 2 drives to swap drives even more easily.
> Runtime_Bad_Block looks acceptable.
> End-to-End_Error and Reported_Uncorrect look perfect. The drives
> should not have corrupted or lost any data (other hardware and/or
> events may have).
OK.
> Airflow_Temperature_Cel and Temperature_Celsius are higher than I
> like. I suggest that you dress cables, add fans, etc., to improve
> cooling.
OK, I'll have a look at that.
> UDMA_CRC_Error_Count for /dev/sda looks worrisome, both compared to
> /dev/sdb and compared to reports for my drives.
>
>
> Total_LBAs_Written for /dev/sda is almost double that of
> /dev/sdb. Where those drives both new when put into RAID1?
Yes, see above. But /dev/sdb was replaced after 9.5 months, so it has
shorter life-time. Also, /dev/sda began to fail every couple of
months about a year ago. I could always fix this by pulling the
drive, re-inserting and re-syncing it. This also caused more
write-traffic to /dev/sda.
> > SMART Extended Self-test Log Version: 1 (1 sectors)
> > Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
> > -# 1 Short offline Completed without error 00% 21808 -
> > +# 1 Short offline Completed without error 00% 14254 -
>
>
> LifeTime for /dev/sda is ~50% higher than /dev/sdb. So, those drives
> were not both new when put into RAID1?
As David has clarified, these are the times of self-tests and current
life times are 51289 hours = 5.9 years and 43740 hours = 5.0 years,
resp.
I have now run a short and a long self-test on both drives and both
drives seem to have no problems:
root@bit:~# smartctl -l selftest /dev/sda ; smartctl -l selftest /dev/sdb
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-5.13.1] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 51316 -
# 2 Short offline Completed without error 00% 51312 -
# 3 Short offline Completed without error 00% 21808 -
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-5.13.1] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 43767 -
# 2 Short offline Completed without error 00% 43764 -
# 3 Short offline Completed without error 00% 14254 -
root@bit:~# smartctl -l error /dev/sda ; smartctl -l error /dev/sdb
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-5.13.1] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART Error Log Version: 1
No Errors Logged
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-5.13.1] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART Error Log Version: 1
No Errors Logged
> The smartctl(8) RAW_VALUE column is tough to read. Sometimes it looks
> like an integer. Other times, it looks like a bitmap or big-endian/
> little-endian mix-up. The VALUE column is easier. Both 119 and 117
> are greater than 100, so I would not worry.
Hm, in some cases the RAW_VALUE looked somehow "more readable, and the
VALUE looked suspicous to me. And here I found the explanation in the
smartctl(8) man page:
Each Attribute has a "Raw" value, printed under the heading
"RAW_VALUE", and a "Normalized" value printed under the
heading "VALUE".
[...]
Each vendor uses their own algorithm to convert this "Raw"
value to a "Normalized" value in the range from 1 to 254.
[...]
So to summarize: the Raw Attribute values are the ones that
might have a real physical interpretation, such as
"Temperature Celsius", "Hours", or "Start-Stop Cycles".
> I replaced all of my SATA I/II/III cables in all of my computers about
> a year ago with Cable Matters black 6G cables with locking straight
> and/or 90 degree connectors. Life got much better.
I think I should replace my cables too, probably not the cheapest ons
I can find.
And I'll also run self-tests and store and keep the results somewhere
more regularly.
Thanks for all your answers, hints, suggestions. With that, and
reading the man page more carefully (mostly motivate by your and
other's answers) I learned quite a lot new about SMART and how to
use/read it.
urs
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2021-07-19 00:50 +0200 |
| Message-ID | <CCnLH-3Mu-1@gated-at.bofh.it> |
| In reply to | #237507 |
On 7/18/21 2:29 PM, Urs Thuermann wrote: > David Christensen <dpchrist@holgerdanske.com> writes: > >> You should consider upgrading to Debian 10 -- more people run that and >> you will get better support. > > It's on my TODO list. As well as upgrading the very old hardware. > Currently, it's a Gigabyte P35-DS3L with an Intel Core2Duo E8400 CPU > and 8 GB RAM. It's only my private home server and performance is > still sufficient but I hope to reduce power consumption considerably. I ran Debian on desktop hardware as a SOHO server for many years, but grew concerned about bit rot. So, I migrated to low-end enterprise hardware and FreeBSD with ZFS. The various SATA battles made things tougher than they should have been, but I fixed several problems and everything is now stable. >>> # diff -U20 <(smartctl -x /dev/sda) <(smartctl -x /dev/sdb) >> >> >> Why limit unified context to 20 lines? You may be missing information >> (I have not counted the differences, below). I suggest '-U' alone. > > 20 lines are just enough to get all. You can see this because there > are less than 20 context lines at the beginning and end of the diff > and only one hunk. GNU diff doesn't allow -U without a line count. Sorry -- I do not use the -U option and misread the diff(1) man page. > Yes, the old Gigabyte mainboard has only 3 Gbps ports. I wasn't aware > of this but have just looked up the specs. SATA2 should be plenty for Seagate ST2000DM001 drives. Two PCIe x1 SATA3 HBA's or one PCIe x2+ SATA3 HBA might improve performance slightly under specific workloads, but I would just stay with motherboard SATA2 ports (unless you find problems with them). > And the server is about 8 years old, initially with only 1 hard drive > which crashed while my backup was too small to hold everything. This > meant a lot of work (and quite some money) to get everything running > again and to recover data which wasn't in the backup. I think we have all been burned by trying to "make do" with inadequate backup devices. I threw money at the problem after my last significant data loss, and now have backups several drives deep. The funny thing is: when you're prepared, the gremlins know it and stay away. ;-) >> The smartctl(8) RAW_VALUE column is tough to read. Sometimes it looks >> like an integer. Other times, it looks like a bitmap or big-endian/ >> little-endian mix-up. The VALUE column is easier. Both 119 and 117 >> are greater than 100, so I would not worry. > > Hm, in some cases the RAW_VALUE looked somehow "more readable, and the > VALUE looked suspicous to me. And here I found the explanation in the > smartctl(8) man page: > > Each Attribute has a "Raw" value, printed under the heading > "RAW_VALUE", and a "Normalized" value printed under the > heading "VALUE". > [...] > Each vendor uses their own algorithm to convert this "Raw" > value to a "Normalized" value in the range from 1 to 254. > [...] > So to summarize: the Raw Attribute values are the ones that > might have a real physical interpretation, such as > "Temperature Celsius", "Hours", or "Start-Stop Cycles". Thank you for the clarification. As usual, I am guilty of inadequate RTFM... > Thanks for all your answers, hints, suggestions. With that, and > reading the man page more carefully (mostly motivate by your and > other's answers) I learned quite a lot new about SMART and how to > use/read it. YW. I am learning too. David
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.user
csiph-web