0

enter image description here

Raid5 on a server is having problems the last two times I rebooted. CentOS does boot up after 10-15 minutes. Is there a way I can scan the raid and repair it? I was reading the man page and mdadm --scan caught my attention but my command was unsuccessful. The raid has no data on it or anything at the moment.

Could this be one of the HDs failed? 2/3 drives are VERY old but aren't used much.

Then I saw the assemble option but the raid is already assembled no?

cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdd[1] sde[3] sdc[0]
      3906762752 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
      bitmap: 0/15 pages [0KB], 65536KB chunk

And

mdadm --detail /dev/md?*
/dev/md0:
           Version : 1.2
     Creation Time : Sat Jul  4 00:09:25 2020
        Raid Level : raid5
        Array Size : 3906762752 (3725.78 GiB 4000.53 GB)
     Used Dev Size : 1953381376 (1862.89 GiB 2000.26 GB)
      Raid Devices : 3
     Total Devices : 3
       Persistence : Superblock is persistent
 
     Intent Bitmap : Internal
 
       Update Time : Wed Sep 30 22:49:32 2020
             State : clean 
    Active Devices : 3
   Working Devices : 3
    Failed Devices : 0
     Spare Devices : 0
 
            Layout : left-symmetric
        Chunk Size : 512K
 
Consistency Policy : bitmap
 
              Name : orcacomputers.orcainbox:0  (local to host orcacomputers.orcainbox)
              UUID : 4ca9118c:3a557d0f:db723ff2:e8b9a521
            Events : 5327
 
    Number   Major   Minor   RaidDevice State
       0       8       32        0      active sync   /dev/sdc
       1       8       48        1      active sync   /dev/sdd
       3       8       64        2      active sync   /dev/sde

A little later,

lsblk /dev/sdf
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdf         8:80     0  7.3T  0 disk

And

mdadm --examine /dev/sdf*
mdadm: No md superblock detected on /dev/sdf





NAME            MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda               8:0    0 447.1G  0 disk  
├─sda1            8:1    0   200M  0 part  /boot/efi
├─sda2            8:2    0     1G  0 part  /boot
└─sda3            8:3    0   446G  0 part  
  ├─centos-root 253:0    0    50G  0 lvm   /
  ├─centos-swap 253:1    0  31.4G  0 lvm   [SWAP]
  └─centos-home 253:2    0 364.5G  0 lvm   /home
sdb               8:16   0 447.1G  0 disk  /run/media/orca/ssd2
sdc               8:32   0   1.8T  0 disk  
└─md0             9:0    0   3.7T  0 raid5 /mnt/raid5
sdd               8:48   0   1.8T  0 disk  
└─md0             9:0    0   3.7T  0 raid5 /mnt/raid5
sde               8:64   0   1.8T  0 disk  
└─md0             9:0    0   3.7T  0 raid5 /mnt/raid5
sdf               8:80   0   7.3T  0 disk

The hard drives look good, they have not failed as per

/dev/sda
smartctl 7.0 2018-12-30 r4883 [x86_64-linux-3.10.0-1127.19.1.el7.x86_64] (local build)
Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
----------------------------------------------------------------------------------------
/dev/sdb
smartctl 7.0 2018-12-30 r4883 [x86_64-linux-3.10.0-1127.19.1.el7.x86_64] (local build)
Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
----------------------------------------------------------------------------------------
/dev/sdc
smartctl 7.0 2018-12-30 r4883 [x86_64-linux-3.10.0-1127.19.1.el7.x86_64] (local build)
Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
----------------------------------------------------------------------------------------
/dev/sdd
smartctl 7.0 2018-12-30 r4883 [x86_64-linux-3.10.0-1127.19.1.el7.x86_64] (local build)
Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
----------------------------------------------------------------------------------------
/dev/sde
smartctl 7.0 2018-12-30 r4883 [x86_64-linux-3.10.0-1127.19.1.el7.x86_64] (local build)
Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
----------------------------------------------------------------------------------------
/dev/sdf
smartctl 7.0 2018-12-30 r4883 [x86_64-linux-3.10.0-1127.19.1.el7.x86_64] (local build)
Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org
Read Device Identity failed: scsi error unsupported field in scsi command



   /dev/sdf is the combination of sdc sdd sde

Here is a list of drives:

    /dev/sda         447.1G
    /dev/sdb         447.1G
    /dev/sdc         1.8T
    /dev/sdd         1.8T
    /dev/sde         1.8T
    /dev/sdf         7.3T

Thanks for any help. I did not set up this raid5.

Improve this question
11
  • Please add cat /proc/mdstat to your question. And mdadm --detail /dev/md*. Both preferably not as a screenshot but as a proper copy and paste because it's really important the details are crystal clear. Your /dev/sdf has failed and I'm curious to see why it's not been kicked out of the array. (By the way, I would suggest you don't try out mdadm commands on a live system without understanding what they do)
    – Chris Davies
    Commented Oct 1, 2020 at 21:45
  • Thanks for response. I had to pastebin the output because it was too long | pastebin.com/rvVwjqtM
    – mister mcdoogle
    Commented Oct 2, 2020 at 18:33
  • What does lsblk /dev/sdf tell you should be on the disk? And what about mdadm --examine /dev/sdf*
    – Chris Davies
    Commented Oct 2, 2020 at 19:46
  • lsblk /dev/sdf NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdf 8:80 0 7.3T 0 disk sudo mdadm --examine /dev/sdf* mdadm: No md superblock detected on /dev/sdf.
    – mister mcdoogle
    Commented Oct 2, 2020 at 23:11
  • 1
    Not according to the RAID subsystem they don't
    – Chris Davies
    Commented Oct 3, 2020 at 16:47

2 Answers 2

Reset to default
1

/dev/sdf has failed and needs to be replaced. The buffer I/O errors are coming from the disk, not mdadm.

AFAIK there is no repair for mdadm as there is nothing to repair, but there is likely a verify option (which I don't think helps you) and, ifckurse, you can remove the failed device and add a new one.

Improve this answer
3
  • sdf is the 7.3TB raid. sdc,sdd,sde make sdf
    – mister mcdoogle
    Commented Oct 3, 2020 at 16:16
  • 1
    No its not. See above.
    – davidgo
    Commented Oct 3, 2020 at 18:15
  • You are correct. I feel like a total knob. The 7.3TB is my external HD, not the Raid5. I had the the external hard drive upside down on the ground. So I unplugged it, turned it right side up then tested it on my laptop successfully; it worked, then put it back on production server and errors went away. face palm So many moving parts to my business...Thank you for your response.
    – mister mcdoogle
    Commented Oct 14, 2020 at 4:17
0

The photograph of your console shows myraid errors from /dev/sdf. The output of /proc/mdstat shows that the RAID5 in question is built from /dev/sdd, /dev/sde, and /dev/sdc, with no missing component.

Therefore the RAID5 is not at risk. You have something else using /dev/sdf, and it is this that will be losing data. (Maybe an unassembled RAID array?)

Improve this answer
1
  • The raid array was assembled previously. Is there a way to see what is trying to use sdf? I haven't done anything with this RAID yet, I was just trying to see if I could get it to show up in "Other Locations" in the File GUI on CentOS
    – mister mcdoogle
    Commented Oct 2, 2020 at 23:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .