tuxbass Posted May 12, 2019 Share Posted May 12, 2019 (edited) Recently upgraded unraid ver, and now discovered one of the three drives (non-parity one) is no longer mounting. It's part of the array, ie not a cache drive; formatted in btrfs. 1) I can't even tell how long i've been having issues with this drive. Shouldn't unraid inform us with a pop-up or something if drive that used to be mounted is no longer operational? 2) what's next - first follow faq on this matter? Am not too sure about the first step (mounting) in that post: For a single device: replace X with actual device, don't forget the 1 in the end, e.g., /dev/sdf1 For a pool: replace X with any of the devices from the pool to mount the whole pool (as long as there are no devices missing), don't forget the 1 in the end, e.g., /dev/sdf1, if the normal read only recovery mount doesn't work, e.g., because there's a damaged or missing device you should use instead: mount -o degraded,usebackuproot,ro /dev/sdX1 /x Replace X with any of the remaining pool devices to mount the whole pool, don't forget the 1 in the end, e.g., /dev/sdf1, if all devices are present and it doesn't mount with the first device you t ried use the other(s), filesystem on one of them may be more damaged then the other(s). Note that if there are more devices missing than the profile permits for redundancy it may still mount but there will be some data missing, e.g., mounting a 4 device raid1 pool with 2 devices missing will result in missing data. As my drive is part of an array, that means it's not a single device but a pool, correct? Regardless, what is even the difference in that excerpt between the single device & pool instructions? Note in my array, the other data drive (that's ok) is mounted as /mnt/md1 (as opposed to /mnt/sdd1); should the faulty drive be mounted from /dev/sde1 or /dev/md2? In any case, tried mounting both, but got "mount(2) system call failed file exists". 3) if no way to recover the file system - isn't this the perfect moment to put parity drive to a good use? -------------------------------------- Relevant bit from syslog: May 12 20:29:13 Tower root: Starting diskload May 12 20:29:13 Tower emhttpd: Mounting disks... May 12 20:29:13 Tower emhttpd: shcmd (993): /sbin/btrfs device scan May 12 20:29:13 Tower root: ERROR: device scan failed on '/dev/md2': File exists May 12 20:29:13 Tower root: ERROR: there are 1 errors while registering devices May 12 20:29:13 Tower root: Scanning for Btrfs filesystems May 12 20:29:13 Tower emhttpd: shcmd (993): exit status: 1 May 12 20:29:13 Tower emhttpd: shcmd (994): mkdir -p /mnt/disk1 May 12 20:29:13 Tower emhttpd: shcmd (995): mount -t btrfs -o noatime,nodiratime /dev/md1 /mnt/disk1 May 12 20:29:13 Tower kernel: BTRFS info (device md1): disk space caching is enabled May 12 20:29:13 Tower kernel: BTRFS info (device md1): has skinny extents May 12 20:29:16 Tower emhttpd: shcmd (996): btrfs filesystem resize max /mnt/disk1 May 12 20:29:16 Tower root: Resize '/mnt/disk1' of 'max' May 12 20:29:16 Tower emhttpd: shcmd (997): mkdir -p /mnt/disk2 May 12 20:29:16 Tower kernel: BTRFS info (device md1): new size for /dev/md1 is 4000786976768 May 12 20:29:16 Tower emhttpd: shcmd (998): mount -t btrfs -o noatime,nodiratime /dev/md2 /mnt/disk2 May 12 20:29:16 Tower root: mount: /mnt/disk2: mount(2) system call failed: File exists. May 12 20:29:16 Tower emhttpd: shcmd (998): exit status: 32 May 12 20:29:16 Tower emhttpd: /mnt/disk2 mount error: No file system May 12 20:29:16 Tower emhttpd: shcmd (999): umount /mnt/disk2 May 12 20:29:16 Tower kernel: BTRFS warning (device md1): duplicate device fsid:devid for c73b4aa5-be66-4536-b0d7-ff172541bbfa:1 old:/dev/md1 new:/dev/md2 May 12 20:29:16 Tower root: umount: /mnt/disk2: not mounted. May 12 20:29:16 Tower emhttpd: shcmd (999): exit status: 32 May 12 20:29:16 Tower emhttpd: shcmd (1000): rmdir /mnt/disk2 May 12 20:29:16 Tower emhttpd: shcmd (1001): mkdir -p /mnt/cache May 12 20:29:16 Tower emhttpd: shcmd (1002): mount -t btrfs -o noatime,nodiratime /dev/sdc1 /mnt/cache Running 6.7.0. Diags: tower-diagnostics-20190512-1831.zip Edited May 12, 2019 by tuxbass Quote Link to comment
JorgeB Posted May 13, 2019 Share Posted May 13, 2019 There appears to be some issue with the UUID, please post the output of: btrfs fi show /dev/sde1 Quote Link to comment
tuxbass Posted May 13, 2019 Author Share Posted May 13, 2019 (edited) root@Tower:~# btrfs fi show /dev/sde1 Label: none uuid: c73b4aa5-be66-4536-b0d7-ff172541bbfa Total devices 1 FS bytes used 384.00KiB devid 1 size 3.64TiB used 1.02GiB path /dev/sde1 ... root@Tower:~# btrfs fi show /dev/sdd1 WARNING: adding device /dev/sde1 gen 16 but found an existing device /dev/sdd1 gen 6712 ERROR: cannot scan /dev/sde1: File exists Label: none uuid: c73b4aa5-be66-4536-b0d7-ff172541bbfa Total devices 1 FS bytes used 2.10TiB devid 1 size 3.64TiB used 2.10TiB path /dev/sdd1 ... root@Tower:~# blkid /dev/sde1 /dev/sde1: UUID="c73b4aa5-be66-4536-b0d7-ff172541bbfa" UUID_SUB="5f56d3d8-f921-4fc5-8116-a08a2961cc32" TYPE="btrfs" PARTUUID="f3b03bdc-d205-4405-b01e-b2f045413e29" ... root@Tower:~# blkid /dev/sdd1 /dev/sdd1: UUID="c73b4aa5-be66-4536-b0d7-ff172541bbfa" UUID_SUB="5f56d3d8-f921-4fc5-8116-a08a2961cc32" TYPE="btrfs" PARTUUID="729740b6-a655-48f3-a493-97318e1249ff" ... root@Tower:~# fdisk -l (only showing relevant drives) Disk /dev/sdd: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors Disk model: WDC WD40EFRX-68W Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 97A12352-C3D3-49DD-8534-74235E24C9FF Device Start End Sectors Size Type /dev/sdd1 64 7814037134 7814037071 3.7T Linux filesystem Disk /dev/sde: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors Disk model: WDC WD40EFRX-68W Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 2D1D29E4-02F1-424D-92A4-C70F879B3F9D Device Start End Sectors Size Type /dev/sde1 64 7814037134 7814037071 3.7T Linux filesystem Both drives have same UUIDs? How's that possible? Not sure if relevant, but server was dormant from the end of 2017 (v 6.3.5) 'til last september when it was upgraded to 6.5.2, followed by 6.6.7 update couple of days ago, and 6.7.0 yesterday. Edited May 14, 2019 by tuxbass Quote Link to comment
JorgeB Posted May 14, 2019 Share Posted May 14, 2019 11 hours ago, tuxbass said: Both drives have same UUIDs? How's that possible? It can't be a coincidence, likely something you did, like cloning a disk, or using a previously rebuilt disk. You can change the UUID with: btrfstune -u /dev/sde1 Since there's a very small risk doing this, do it on disk2 because it's empty, you could even format it. Quote Link to comment
tuxbass Posted May 14, 2019 Author Share Posted May 14, 2019 (edited) Quote like cloning a disk, or using a previously rebuilt disk Was thinking the same thing, only that I'm 100% sure I haven't touched the array disks after the setup was built in the beginning. Is it possible there's some shortcut for it on the webUI, and this was done unintentionally? Or anything else that could've caused this? Quote do it on disk2 because it's empty, you could even format it Are you sure that "used 1.02GiB" isn't actual data? I'm almost sure disk2 did contain something. But can't recall 100% as the server was dormant for a year or so. Edited May 14, 2019 by tuxbass Quote Link to comment
JorgeB Posted May 14, 2019 Share Posted May 14, 2019 45 minutes ago, tuxbass said: Is it possible there's some shortcut for it on the webUI, and this was done unintentionally? Or anything else that could've caused this? Can't see how, but there might be another explanation. 45 minutes ago, tuxbass said: Are you sure that "used 1.02GiB" isn't actual data? No, that's the allocated size, used is 13 hours ago, tuxbass said: Total devices 1 FS bytes used 384.00KiB 1 Quote Link to comment
tuxbass Posted May 14, 2019 Author Share Posted May 14, 2019 Right, that's odd. Guess at this point I should be following the new drive addition tutorial (ie. format & preclear), and re-add it to the array? In any case, cheers for your help man, much obliged. Quote Link to comment
JorgeB Posted May 14, 2019 Share Posted May 14, 2019 You just need to change the UUID (or format it). Quote Link to comment
tuxbass Posted May 14, 2019 Author Share Posted May 14, 2019 How come preclear can be skipped - doesn't this break the partiy as per wiki? Quote Link to comment
JorgeB Posted May 14, 2019 Share Posted May 14, 2019 Disk is already part of the array, formatting keeps parity in sync, changing just the UUID on the sdX device won't, though a parity check would fix it, but if you do it with the array started, and since the disk isn't mounting, you can use the md device and that will also maintain parity: btrfstune -u /dev/md2 Quote Link to comment
tuxbass Posted May 14, 2019 Author Share Posted May 14, 2019 Right, went on to generate new UUID via btrfstune -u /dev/sde1 and everything looked good. Started array, drive was added to array no problem. Then I started moving everything from cache to array (need to change cache drive) by invoking mover, which led to issues with drive, and unraid showing drive as disabled; see https://i.imgur.com/gwwUaQS.png and https://i.imgur.com/OL3olqv.png Note the mover didn't actually stop; waited until mover was done, and data can be seen under disk2. Under syslog bunch of read & write errors can be seen; is it okay to trust this data? How likely something's corrupted? (in syslog, mover is started on line "May 14 20:27:39 Tower emhttpd: req (9): cmdStartMover=Move+now&csrf_token=****************") tower-diagnostics-20190514-1941.zip Quote Link to comment
JorgeB Posted May 15, 2019 Share Posted May 15, 2019 Data should be fine, though there's a small chance the file being written when the disk started being emulated is corrupt. This problem is an unrelated hardware problem, start by running an extended SMART test on that disk. Quote Link to comment
tuxbass Posted May 16, 2019 Author Share Posted May 16, 2019 This is never-ending. After reboot, drive 2 is unmountable again; this time seems to be a different issue. Not too sure what to do anymore. Judging by the used data on disk2, I guess it's safe to say the data is all gone? May 16 21:09:10 Tower kernel: BTRFS info (device md2): disk space caching is enabled May 16 21:09:10 Tower kernel: BTRFS info (device md2): has skinny extents May 16 21:09:10 Tower kernel: BTRFS error (device md2): bad fsid on block 21020672 May 16 21:09:10 Tower kernel: BTRFS warning (device md2): failed to read root (objectid=9): -5 May 16 21:09:10 Tower root: mount: /mnt/disk2: wrong fs type, bad option, bad superblock on /dev/md2, missing codepage or helper program, or other error. May 16 21:09:10 Tower emhttpd: shcmd (4240): exit status: 32 May 16 21:09:10 Tower emhttpd: /mnt/disk2 mount error: No file system May 16 21:09:10 Tower emhttpd: shcmd (4241): umount /mnt/disk2 May 16 21:09:10 Tower kernel: BTRFS error (device md2): open_ctree failed root@Tower:/mnt# fdisk -l Disk /dev/sde: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors Disk model: WDC WD40EFRX-68W Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 2D1D29E4-02F1-424D-92A4-C70F879B3F9D Device Start End Sectors Size Type /dev/sde1 64 7814037134 7814037071 3.7T Linux filesystem Disk /dev/sdd: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors Disk model: WDC WD40EFRX-68W Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 97A12352-C3D3-49DD-8534-74235E24C9FF Device Start End Sectors Size Type /dev/sdd1 64 7814037134 7814037071 3.7T Linux filesystem Disk /dev/md1: 3.7 TiB, 4000786976768 bytes, 7814037064 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/md2: 3.7 TiB, 4000786976768 bytes, 7814037064 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes root@Tower:/mnt# blkid /dev/sde1 /dev/sde1: UUID="10fe804c-e43d-4d9c-b225-551fac35006c" UUID_SUB="5f56d3d8-f921-4fc5-8116-a08a2961cc32" TYPE="btrfs" PARTUUID="f3b03bdc-d205-4405-b01e-b2f045413e29" root@Tower:/mnt# blkid /dev/sdd1 /dev/sdd1: UUID="c73b4aa5-be66-4536-b0d7-ff172541bbfa" UUID_SUB="5f56d3d8-f921-4fc5-8116-a08a2961cc32" TYPE="btrfs" PARTUUID="729740b6-a655-48f3-a493-97318e1249ff" root@Tower:/mnt# btrfs fi show /dev/sde1 Label: none uuid: 10fe804c-e43d-4d9c-b225-551fac35006c Total devices 1 FS bytes used 233.10MiB devid 1 size 3.64TiB used 2.02GiB path /dev/md2 root@Tower:/mnt# btrfs fi show /dev/sdd1 Label: none uuid: c73b4aa5-be66-4536-b0d7-ff172541bbfa Total devices 1 FS bytes used 2.10TiB devid 1 size 3.64TiB used 2.10TiB path /dev/md1 tower-diagnostics-20190516-1919.zip Quote Link to comment
JorgeB Posted May 17, 2019 Share Posted May 17, 2019 11 hours ago, tuxbass said: bad fsid on block 21020672 This makes me thinks is still related to the UUID issue, you can try changing it again, but even if it works probably best to backup and reformat the disk. If the UUID change doesn't help and you want to try and recover any data before formatting try the btrfs recovery options on the FAQ. 1 Quote Link to comment
tuxbass Posted May 20, 2019 Author Share Posted May 20, 2019 (edited) > This makes me thinks is still related to the UUID issue You were right again. This time started array & changed UUID of /dev/md2 (as opposed to /dev/sde1) and drive now mounts every time upon reboot. The drive is still marked as 'disabled' in array though. Tried re-adding it to the array by taking it off of it, re-adding, and doing the data re-build from the parity drive. At the beginning of rebuild it threw some IO errors as before; chose to 'continue' the rebuild in webui, then after some 9h it was done. From what I can see, it has the same data as before rebuild (which includes the data I copied there from cache when I started seeing the IO errors in syslog. No guarantee, but form what i can see, all the data is there). As mentioned, disk2 (/dev/sde1) mounts now every time when array is brought on-line, but drive still shows as 'disabled' in webui; is it because of the IO errors during rebuild? Should I pull the drive from the array once again and reformat as you suggested? Should a re-build from parity be attempted in that case? Adding longs just in case - from the time when drive was re-enabled in array and data rebuilt form parity (think it starts at line 'May 19 04:03:14 Tower kernel: md: recovery thread: recon D2 ..', and other logs after system was rebooted, and no obvious errors can no longer be seen in syslog. tower-diagnostics-20190519-1821_disk2_recovery.zip tower-diagnostics-20190520-0415_current.zip Edited May 20, 2019 by tuxbass Quote Link to comment
JorgeB Posted May 20, 2019 Share Posted May 20, 2019 This time looks more like a connection issue, replace cables, though you still havn't run the SMART extended test as suggested. Quote Link to comment
tuxbass Posted May 21, 2019 Author Share Posted May 21, 2019 (edited) Missed the SMART test bit. Ran it overnight, full diag included. tl;dr: no errors found. Will proceed to check the cables tonight. tower-diagnostics-20190521-1740_SMART.zip Edit: tried swapping cables with sdd drive, still the same. Tried formatting the drive - still same. Is it possible that format + not going through data re-build (how to achieve that?) might help? Edited May 22, 2019 by tuxbass Quote Link to comment
tuxbass Posted May 25, 2019 Author Share Posted May 25, 2019 (edited) Got also extra cables, just in case; tried different SATA ports on the MOBO - still no go. Now I feel like smartmontools were incorrectly reporting non-error state. Yesterday opened smart check for the drive, and the smart test history showed "Completed without error" for all the jobs, yet there are 3 reports of UNC sectors at LBA: Error 3 occurred at disk power-on lifetime: 7531 hours (313 days + 19 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 06 c2 00 00 e0 Error: UNC 6 sectors at LBA = 0x000000c2 = 194 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 06 c2 00 00 e0 08 00:11:36.012 READ DMA ef 10 02 00 00 00 a0 08 00:11:36.012 SET FEATURES [Enable SATA feature] ec 00 00 00 00 00 a0 08 00:11:36.011 IDENTIFY DEVICE ef 03 46 00 00 00 a0 08 00:11:36.011 SET FEATURES [Set transfer mode] Error 2 occurred at disk power-on lifetime: 7531 hours (313 days + 19 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 01 c1 00 00 e0 Error: UNC 1 sectors at LBA = 0x000000c1 = 193 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 01 c1 00 00 e0 08 00:11:28.997 READ DMA ef 10 02 00 00 00 a0 08 00:11:28.997 SET FEATURES [Enable SATA feature] ec 00 00 00 00 00 a0 08 00:11:28.996 IDENTIFY DEVICE ef 03 46 00 00 00 a0 08 00:11:28.996 SET FEATURES [Set transfer mode] Error 1 occurred at disk power-on lifetime: 7531 hours (313 days + 19 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 01 c0 00 00 e0 Error: UNC 1 sectors at LBA = 0x000000c0 = 192 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 01 c0 00 00 e0 08 00:11:21.982 READ DMA ef 10 02 00 00 00 a0 08 00:05:27.450 SET FEATURES [Enable SATA feature] ec 00 00 00 00 00 a0 08 00:05:27.449 IDENTIFY DEVICE ef 03 46 00 00 00 a0 08 00:05:27.449 SET FEATURES [Set transfer mode] SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 7530 - # 2 Extended offline Completed without error 00% 7518 - # 3 Short offline Completed without error 00% 7445 - # 4 Short offline Completed without error 00% 7412 - ^ note all statuses of latest checks are marked as completed w/o error. Now I ran couple of additional short tests, and at least it admits erroneous state; latest report: root@Tower:~# smartctl -a /dev/sde smartctl 7.0 2018-12-30 r4883 [x86_64-linux-4.19.41-Unraid] (local build) Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: Western Digital Red Device Model: WDC WD40EFRX-68WT0N0 Serial Number: WD-WCC4E3KNSS6C LU WWN Device Id: 5 0014ee 2b7cd5d6e Firmware Version: 82.00A82 User Capacity: 4,000,787,030,016 bytes [4.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate: 5400 rpm Device is: In smartctl database [for details use: -P show] ATA Version is: ACS-2 (minor revision not indicated) SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Sat May 25 17:37:47 2019 CEST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 115) The previous self-test completed having the read element of the test failed. Total time to complete Offline data collection: (52860) 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: ( 2) minutes. Extended self-test routine recommended polling time: ( 529) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. SCT capabilities: (0x703d) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 104 3 Spin_Up_Time 0x0027 218 180 021 Pre-fail Always - 6091 4 Start_Stop_Count 0x0032 099 099 000 Old_age Always - 1259 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 188 188 000 Old_age Always - 393 9 Power_On_Hours 0x0032 090 090 000 Old_age Always - 7540 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 - 100 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 55 193 Load_Cycle_Count 0x0032 198 198 000 Old_age Always - 6035 194 Temperature_Celsius 0x0022 115 104 000 Old_age Always - 37 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 100 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 24 SMART Error Log Version: 1 ATA Error Count: 3 CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 3 occurred at disk power-on lifetime: 7531 hours (313 days + 19 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 06 c2 00 00 e0 Error: UNC 6 sectors at LBA = 0x000000c2 = 194 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 06 c2 00 00 e0 08 00:11:36.012 READ DMA ef 10 02 00 00 00 a0 08 00:11:36.012 SET FEATURES [Enable SATA feature] ec 00 00 00 00 00 a0 08 00:11:36.011 IDENTIFY DEVICE ef 03 46 00 00 00 a0 08 00:11:36.011 SET FEATURES [Set transfer mode] Error 2 occurred at disk power-on lifetime: 7531 hours (313 days + 19 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 01 c1 00 00 e0 Error: UNC 1 sectors at LBA = 0x000000c1 = 193 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 01 c1 00 00 e0 08 00:11:28.997 READ DMA ef 10 02 00 00 00 a0 08 00:11:28.997 SET FEATURES [Enable SATA feature] ec 00 00 00 00 00 a0 08 00:11:28.996 IDENTIFY DEVICE ef 03 46 00 00 00 a0 08 00:11:28.996 SET FEATURES [Set transfer mode] Error 1 occurred at disk power-on lifetime: 7531 hours (313 days + 19 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 01 c0 00 00 e0 Error: UNC 1 sectors at LBA = 0x000000c0 = 192 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 01 c0 00 00 e0 08 00:11:21.982 READ DMA ef 10 02 00 00 00 a0 08 00:05:27.450 SET FEATURES [Enable SATA feature] ec 00 00 00 00 00 a0 08 00:05:27.449 IDENTIFY DEVICE ef 03 46 00 00 00 a0 08 00:05:27.449 SET FEATURES [Set transfer mode] SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed: read failure 30% 7540 4296320 # 2 Short offline Completed: read failure 10% 7540 4329336 # 3 Short offline Completed without error 00% 7540 - # 4 Short offline Completed without error 00% 7530 - # 5 Extended offline Completed without error 00% 7518 - # 6 Short offline Completed without error 00% 7445 - # 7 Short offline Completed without error 00% 7412 - 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. Could this be the root of it all? Can this be recovered from? Have read soft bad sectors might be recovered by writing zeros over them. Is that the case? Edited May 25, 2019 by tuxbass Quote Link to comment
JorgeB Posted May 26, 2019 Share Posted May 26, 2019 A full disk write can sometimes fix the problem, but looking at the SMART report I would recommend replacing it. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.