[btrfs] Unmountable: No file system


Recommended Posts

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 by tuxbass
Link to comment
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 by tuxbass
Link to comment
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.

Link to comment
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 by tuxbass
Link to comment
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

 

  • Like 1
Link to comment

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

 

Link to comment

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

Link to comment

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

Link to comment
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.

  • Upvote 1
Link to comment

> 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 by tuxbass
Link to comment

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 by tuxbass
Link to comment

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 by tuxbass
Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.