July 28, 201213 yr I just fired up the Unraid console to check some info and noticed that one of my disks is showing 182 errors but is still green balled not disabled. The drive is a WD20EARS that I recently added to replace another smaller drive that had shown some errors, it was precleared with the advanced format flag prior to being added. My understanding is that if the disk has errors but isn't disabled then they are read errors not write errors. Interestingly the UnMenu console screen does not show any errors for this drive. I ran a Smart report for the drive and got this :- Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 163 156 021 Pre-fail Always - 6850 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 444 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 9 Power_On_Hours 0x0032 095 095 000 Old_age Always - 3877 10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 255 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 85 193 Load_Cycle_Count 0x0032 197 197 000 Old_age Always - 9869 194 Temperature_Celsius 0x0022 123 104 000 Old_age Always - 27 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 30 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 13 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 2 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 32 Obviously those last 4 are of concern but I'm not sure what to do next. As it happens I've acquired another Hitachi 5K3000 disk (same model as the other 5 Hitachis I have in the Tardis) so I can swap the disk out if needed. Should I run a parity check before swapping the disk and should it be a correcting one or is non-correcting safer?
July 28, 201213 yr A parity check will not help in this case. The disk need to be rebuilt. Un-assign the disk and start the array. Then assign the disk and restart the array. The disk will be rebuilt. The Current_Pending_Sector should go to zero. Alternatively, replace with a pre-cleared spare and pre-clear the faulty disk. If the pre-clear is successful then the disk becomes the new spare.
July 28, 201213 yr Author Thanks for the response. The only way I can preclear the spare disk is to take out the errored one and put the spare one in it's place, I have no vacant slots in the Tardis. I'm assuming that would be OK? Now that I think of it the power did get cut to the Tardis during the week (chord was knocked out of the plug by accident). I didn't notice the errors at the time but I'm guessing this is what caused the errors.
July 28, 201213 yr In this case I would try to rebuild the existing disk first. Then post a new SMART report.
July 28, 201213 yr Author OK, shall do. ETA: I stopped the array and unassigned the disk which changed the status to "Missing". I wasn't able to start the array without the missing disk so I just re-assigned it then started the array again; it didn't seem to initiate a rebuild. The error count on the main console screen has gone back to 0 however the SMART stats haven't changed :- ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 162 156 021 Pre-fail Always - 6883 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 445 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 9 Power_On_Hours 0x0032 095 095 000 Old_age Always - 3880 10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 255 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 85 193 Load_Cycle_Count 0x0032 197 197 000 Old_age Always - 9878 194 Temperature_Celsius 0x0022 120 104 000 Old_age Always - 30 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 30 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 13 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 2 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 32 Where to from here?
July 28, 201213 yr Stop the array. Un-assign the disk. Start the array. Stop the array. Assign the disk.
July 29, 201213 yr Author Ah, I see what the problem was now; just had to tick the "I'm sure I want to do this" box with the disk unassigned to restart the array. I've followed your directions and the rebuild is now in progress.
July 29, 201213 yr Author SMART status after rebuild :- ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 179 156 021 Pre-fail Always - 6050 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 450 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 9 Power_On_Hours 0x0032 095 095 000 Old_age Always - 3907 10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 255 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 85 193 Load_Cycle_Count 0x0032 197 197 000 Old_age Always - 9894 194 Temperature_Celsius 0x0022 120 104 000 Old_age Always - 30 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 13 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 2 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 32 Pending sectors has returned to 0 but what about those last 3 attributes?
July 29, 201213 yr Those RAW values have meaning only to the manufacturer. As long as the normalized VALUE is above THRESH the disk is not failing. The following RAW values can be read literally: 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 450 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 9 Power_On_Hours 0x0032 095 095 000 Old_age Always - 3907 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 255 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 85 193 Load_Cycle_Count 0x0032 197 197 000 Old_age Always - 9894 194 Temperature_Celsius 0x0022 120 104 000 Old_age Always - 30 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
July 30, 201213 yr Author OK, so looks like my disk is fine then. I want to swap it out anyway purely because the Hitachi drive has 512 byte sectors (the current WD has 4K ones); I'm assuming the process would be the same as for swapping out a failed disk.
July 30, 201213 yr OK, so looks like my disk is fine then. I want to swap it out anyway purely because the Hitachi drive has 512 byte sectors (the current WD has 4K ones); I'm assuming the process would be the same as for swapping out a failed disk. Yes it is. But why does the sector size matter?
July 30, 201213 yr Author But why does the sector size matter? Less wasted space (admittedly more of a benefit with smaller files). The rest of the disks in the array are all 512 byte Hitachi's, thought it made more sense to have them all matched. Also I'm assuming my WD EARS drive has the wonderful head park issue, I haven't done anything to stop that (don't know how).
July 30, 201213 yr But why does the sector size matter? Less wasted space (admittedly more of a benefit with smaller files). The rest of the disks in the array are all 512 byte Hitachi's, thought it made more sense to have them all matched. Also I'm assuming my WD EARS drive has the wonderful head park issue, I haven't done anything to stop that (don't know how). The disk is doing a little over 2 loads(parks) per hour. This is not an issue. I don't think that your saving enough space to offset the effort.
July 30, 201213 yr But why does the sector size matter? Less wasted space (admittedly more of a benefit with smaller files). In my opinion, meaningless. The disks are ALL presenting 512 byte sectors to the OS (regardless of how they do their internal housekeeping) and the ALL present the exact same number of sectors to the OS, therefore, there is no space gained, or lost, regardless of the size files you are storing. The reiserfs itself uses 4k blocks as far as I remember, so it is there you lose some efficiencies if you are storing mostly files that are under 4096 bytes. Since most of the space on my disks hold files MUCH larger than 4096 bytes, the on-disk-sectors size does not matter. The rest of the disks in the array are all 512 byte Hitachi's, thought it made more sense to have them all matched. Does not matter at all in unRAID. Disks do not have to match in any way. Sorry to say, you are being Obsessive-Compulsive...
July 30, 201213 yr Since most of the space on my disks hold files MUCH larger than 4096 bytes, the on-disk-sectors size does not matter. Sorry, but my pedantic nature is kicking in. All files end within a sector, so on average, you are losing roughly 1/2 the sector size * number of files. This can be significant even if all the files are larger than 4K. As you said though, I don't think internal disk housekeeping has anything to do with it, the file system is the only thing that matters in this regard.
July 30, 201213 yr Since most of the space on my disks hold files MUCH larger than 4096 bytes, the on-disk-sectors size does not matter. Sorry, but my pedantic nature is kicking in. All files end within a sector, so on average, you are losing roughly 1/2 the sector size * number of files. True.This can be significant even if all the files are larger than 4K. False. Pretend I have 20 100Gig backup files on a 2TB disk. (20 files total) I've "wasted" 20 * (4k/2) space (40k out of 2TB). the issue you are describing is only if all the files are SMALLER than 4k. As you said though, I don't think internal disk housekeeping has anything to do with it, the file system is the only thing that matters in this regard. Exactly, and it is why 512byte alignment vs 4096byte alignment on the physical disk makes absolutely no difference in most cases. That is the "internal disk housekeeping" It only matters for efficiency if the disk firmware is poorly written and cylinders not cached. (as in WD EARS drives) Since the majority of every disk for the past 20 or so years has had a windows file system starting on an odd numbered 512 byte boundary, that firmware in that first WD EARS disk was poorly designed. It works, but not as efficiently as it might otherwise. The reiserfs file system is always 4k blocks, and you cannot change that. the actual block size matters only if you are storing millions of small files (< 4k), where potentially half the space is not utilized effectively, and that does not really matter with media stored on today's larger disks. (When was the last time you had a media file that occupied a fraction of 4096 bytes?) I have read though that reiserfs uses that unused space once the disk starts getting full, and that is one reason it gets much slower when nearly full (since the disk heads have to move around a lot more to get to the parts of a file).
July 30, 201213 yr Pretend I have 20 100Gig backup files on a 2TB disk. (20 files total) I've "wasted" 20 * (4k/2) space (40k out of 2TB). the issue you are describing is only if all the files are SMALLER than 4k. One of us is missing the point. Say I have 100,000 files, ranging in size from 100k to 1GB. I'm "wasting" 100,000 * 2,000 = 200MB roughly. NONE of those files is below 4K. The important numbers are number of files and cluster size, minimum file size is irrelevant. Even a 100GB file can "waste" 3.9k. Granted, it's a drop in the bucket, but it's still waste. One of my shares contains over 600,000 files.
July 31, 201213 yr Author Does not matter at all in unRAID. Disks do not have to match in any way. Sorry to say, you are being Obsessive-Compulsive... I got the Hitachi for a good price and like that they run so cool. I will use the WD for backups so it's not wasted.
August 12, 201213 yr Author Update: Swapped out the WD drive for the HItachi with no issues, parity check (non-correcting) all good. Marking case as solved.
Archived
This topic is now archived and is closed to further replies.