Raid1 problem

[Konrád Lőrinczi]

Using RC4. 

If I pull out one of the disks (sdb) from a clean array, after power on it becomes inactive, not degraded.

Can not turn it on with Start button in Disks / Raid. 

Any idea, why? 

[Konrád Lőrinczi]

I had to do the following:

[root@dns320]#

mdadm --stop /dev/md0
mdadm: stopped /dev/md0

[root@dns320]#

mdadm --assemble --scan
mdadm: /dev/md/0 has been started with 1 drive (out of 2).

 [root@dns320]# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.0
  Creation Time : Sun Sep 17 14:15:30 2017
     Raid Level : raid1
     Array Size : 487859236 (465.26 GiB 499.57 GB)
  Used Dev Size : 487859236 (465.26 GiB 499.57 GB)
   Raid Devices : 2
  Total Devices : 1
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Sun Sep 17 16:09:32 2017
          State : active, degraded
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0

           Name : dns320:0  (local to host dns320)
           UUID : ....
         Events : 1033

    Number   Major   Minor   RaidDevice State
       0       8        2        0      active sync   /dev/sda2
       1       0        0        1      removed

Now the status page shows the following:

md0

465.3GB

raid1

clean

degraded

idle

I hope this helps somebody, who finds similar situation.

[Konrád Lőrinczi]

I have a further problem, when checing the degraded RAID array:

fsck.ext4 /dev/md0
e2fsck 1.41.14 (22-Dec-2010)
The filesystem size (according to the superblock) is 121964928 blocks
The physical size of the device is 121964809 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? no

/dev/md0 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/md0: 11/30498816 files (0.0% non-contiguous), 1964846/121964928 blocks

But it is not fixed, if I start again, it shows the same size error...

[Konrád Lőrinczi]

I'm lucky, that RAID array is empty at this moment, so I fixed the problem with reformatting md0 to ext4.

Now it's clean.

[João Cardoso]

RC4 is pretty old... hopefuly that is now fixed.

I remember that in some Alt-F version auto assembling degraded RAID1 was disabled, as users could not be aware of its state and continue using the box in that circumstances. Not having any file available would raise their attention.

[Konrád Lőrinczi]

I didn't upgrade to latest one, because I did read performance and network corruption problems in later than RC4 versions.

File transfer speed is higher in RC4, than in latest 1.0 snapshot version, right?

[João Cardoso]

On Sunday, 17 September 2017 19:16:54 UTC+1, Konrád Lőrinczi wrote:

I have a further problem, when checing the degraded RAID array:

fsck.ext4 /dev/md0
e2fsck 1.41.14 (22-Dec-2010)
The filesystem size (according to the superblock) is 121964928 blocks
The physical size of the device is 121964809 blocks

That means that the filesystem is bigger then the device (by 121964928 - 121964809 blocks, ~500KB)

I guess that the filesystem was created before the RAID was created. That will not work! The filesystem has to be created on the new RAID device, not on its components.

At filesystem creation on the RAID device, the RAID device will reserve a certain amount of the disk for itself, and the filesystem will receive a smaller amount of disk space.

If a RAID is created on a physical device that already has a filesystem on it, the RAID creation will not erase the existing filesystem, but latter on, after assembling the RAID, there will be a mismatch between the size stored on the filesystem and the one given by the RAID device to the filesystem.

RAID1 with format 0.9 and 1.0 will store its metadata at the end of the device (hidding it to the fs), and unless the filesystem is 100% full that will not touch any user data on it. It it thus possible to create a RAID1 with v 0.9 or 1.0 over en existing filesystem and keep the data, but that requires special handling.

[Konrád Lőrinczi]

Thanks for the explanation!

Today I learned something again.