mdadm

Software RAID in Linux (mdadm) implements many possibilities to reshape the array including

• changing the type of the array,
• changing the array size (by adding new disks),
• and even changing the block size in RAID 5 or RAID 6.

http://neil.brown.name/blog/20090817000931#4.

RAID type migrations

Can I change the RAID type after the data was written on the array?

Tom's Hardware answers "No"

In fact, it depends on the particular RAID implementation.

• In some implementations you can change nothing.


• In others, you can extend an array by adding new disks.


• There are also the implementations which allow you to even change the array
  type (although not in all combinations).

You need to consult your particular hardware and/or software manual for a list of available options before committing to a certain expansion plan. In any case, make sure to backup the array contents before expanding or migrating to the different array type. Should the migration process fail midway, the RAID recovery is not going to be cheap.

On critical error messages

If a situation occurs that requires immediate user response, then the error message should exactly describe the situation and possible courses of action.

The warning message should be displayed explicitly, because one cannot expect that the user is able to reliably draw conclusions by comparing several independent parameters.

Imaging RAIDs

If you recover RAID and need to create a RAID image file, you should create the image files of the member disks rather than the whole array. Generally, it is not possible to restore the original array state using a RAID image file.

As for RAID0, the original state can be restored by writing the image to the array provided that the controller's settings (and thus the array parameters) have not been changed. If the controller's settings have been changed between reading and writing the image file, then image file data doesn't go to the original place on the member disks.

For RAID5 it is not enough to have a RAID image file of the entire array even if the controller's settings have not been changed. This is because the parity data is not written to the image file. If the array works properly, the parity data is not used, but for the RAID recovery you need the parity data. A RAID5 consisting of 3x1TB disks contains 3TB of raw data (with parity), while the array image file will be 2TB in size and, obviously, does not contain all the data.

The image file of the whole RAID, which was copied using an incorrectly configured controller, is a mess of the block parts and it can only be used provided that you know what the controller's settings were when creating the RAID image file. As of 2010, we know of no software capable of recovering such array image files.

CHKDSK is not the tool to check the disk.

In fact, CHKDSK only checks the filesystem, regardless of where it is located and what state of corresponding physical storage is. The filesystem may be located on a RAID 5 in which one of the member disks has already failed. In this case, from the CHKDSK's point of view, the filesystem is still OK.

One should understand that the data storage system consists of several levels and every level should be checked using the appropriate tools and techniques. For example,

1. A database should be checked using whatever tool is provided with the SQL server.
2. The volume that stores the database should be checked by CHKDSK.
3. The RAID that contains the volume should be checked using diagnostic tools provided with the RAID controller.
4. The member disks, should the need arise, should be checked by their corresponding vendor diagnostic tools.

Sounds a bit like "The House that Jack Built".