My current idea is to create one software array, class RAID-6, with 4 member drives, using mdadm.
Specifically, the drives would be 1 TB HDDs on SATA in a small server Dell T20.
Operating System is GNU/Linux Debian 8.6 (later upgraded: Jessie ⟶ Stretch ⟶ Buster)
That would make 2 TB of disk space with 2 TB of parity in my case.
I would also like to have it with GPT partition table, for that to work, I am unsure how to proceed specifically supposing I would prefer to do this purely over the terminal.
As I never created a RAID array, could you guide me on how I should proceed?
Notes:
- This array will serve for the sole data only. No boot or OS on it.
- I opted for RAID-6 due to the purpose of this array. Two drive failures the array must be able to survive. Since I am limited by hardware to 4 drives, there is no alternative to RAID-6 that I know of. (However ugly the RAID-6 slowdown may seem, it does not matter in this array.)
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
In this answer, let it be clear that all data will be destroyed on all of the array members (drives), so back it up first!
Open terminal and become root (su); if you have sudo enabled, you may also do for example sudo -i; see man sudo for all options):
sudo -i
First, we should erase the drives, if there was any data and filesystems before, that is. Suppose we have 4 members: sdi, sdj, sdk, sdl. For the purpose of having feedback of this process visually, the pv (pipe viewer) was used here:
pv < /dev/zero > /dev/sdi pv < /dev/zero > /dev/sdj pv < /dev/zero > /dev/sdk pv < /dev/zero > /dev/sdl
Alternatively, to just check if there is nothing left behind, you may peek with GParted on all of the drives, and if there is any partition with or without any filesystem, wiping it could be enough, though I myself prefer the above zeroing all of the drives involved, remember to un-mount all partitions before doing so, it could be done similar to these one-liners:
umount /dev/sdi?; wipefs --all --force /dev/sdi?; wipefs --all --force /dev/sdi umount /dev/sdj?; wipefs --all --force /dev/sdj?; wipefs --all --force /dev/sdj umount /dev/sdk?; wipefs --all --force /dev/sdk?; wipefs --all --force /dev/sdk umount /dev/sdl?; wipefs --all --force /dev/sdl?; wipefs --all --force /dev/sdl
Then, we initialize all drives with GUID partition table (GPT), and we need to partition all of the drives, but don’t do this with GParted, because it would create a filesystem in the process, which we don’t want, use gdisk instead:
gdisk /dev/sdi gdisk /dev/sdj gdisk /dev/sdk gdisk /dev/sdl
In all cases use the following:
o Enter for new empty GUID partition table (GPT)
y Enter to confirm your decision
n Enter for new partition
Enter for default of first partition
Enter for default of the first sector
Enter for default of the last sector
fd00 Enter for Linux RAID type
w Enter to write changes
y Enter to confirm your decision
You can examine the drives now:
mdadm --examine /dev/sdi /dev/sdj /dev/sdk /dev/sdl
It should say:
(type ee)
If it does, we now examine the partitions:
mdadm --examine /dev/sdi1 /dev/sdj1 /dev/sdk1 /dev/sdl1
It should say:
No md superblock detected
If it does, we can create the RAID6 array:
mdadm --create /dev/md0 --level=6 --raid-devices=4 /dev/sdi1 /dev/sdj1 /dev/sdk1 /dev/sdl1
We should wait until the array is fully created, this process we can easily watch:
watch cat /proc/mdstat
After the creation of the array, we should look at its detail:
mdadm --detail /dev/md0
It should say:
State : clean
Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0
Now we create a filesystem on the array, if you use ext4, the below hidden command is better to be avoided, because of ext4lazyinit would take noticeable amount of time in case of a large array, hence the name, “lazyinit“, therefore I recommend you to avoid this one:
mkfs.ext4 /dev/md0
Instead, you should force a full instant initialization (with 0% reserved for root as it is a data array):
mkfs.ext4 -m 0 -E lazy_itable_init=0,lazy_journal_init=0 /dev/md0
By specifying these options, the inodes and the journal will be initialized immediately during creation, useful for larger arrays.
If you chose to take a shortcut and created the ext4 filesystem with the “better avoided command”, note that ext4lazyinit will take noticeable amount of time to initialize all of the inodes, you may watch it until it is done, e.g. with iotop or nmon.
Either way you choose to make the file system initialization, you should mount it after it has finished its initialization.
We now create some directory for this RAID6 array:
mkdir -p /mnt/raid6
And simply mount it:
mount /dev/md0 /mnt/raid6
Since we are essentially done, we may use GParted again to quickly check if it shows linux-raid filesystem, together with the raid flag on all of the drives.
If it does, we properly created the RAID6 array with GPT partitions and can now copy files on it.
See what UUID the md filesystem has:
blkid /dev/md0
Copy the UUID to clipboard.
Now we need to edit fstab, with your favorite text editor, I used nano, though sudoedit might better be used:
nano /etc/fstab
And add add an entry to it:
UUID=<the UUID you have in the clipboard> /mnt/raid6 ext4 defaults 0 0
I myself do not recommend using defaults set of flags, I merely wanted the line not to be overly complex.
Here is what mount flags I use on a UPS backed-up data RAID (instead of defaults):
nofail,nosuid,nodev,noexec,nouser,noatime,auto,async,rw,data=journal,errors=remount-ro
You may check if it is correct after you save the changes:
mount -av | grep raid6
It should say:
already mounted
If it does, we save the array configuration; in case you don’t have any md device yet created, you can simply do:
mdadm --detail --scan >> /etc/mdadm/mdadm.conf
In case there are arrays already existent, just run the previous command without redirection to the config file:
mdadm --detail --scan
and add the new array to the config file manually.
In the end, don’t forget to update your initramfs, because otherwise your new array will only auto read-only assemble, probably as /dev/md127 or similar:
update-initramfs -u -k all
Check if you did everything according to plan, and if so, you may restart:
reboot
Method 2
If you create the RAID arrays over 4 raw block devices instead of 2 x 4 partitions, that means all RAID recovery operations may necessarily operate on the whole devices, and vice versa.
So for example if you expect the disks to eventually start developing I/O errors on the latter half of them, with the arrays over partitions that would mean that only one of the arrays would notice, while the other would continue untouched, at least until the damage spreads into its half. This might provide you with some temporary flexibility, or an absence of I/O slowdown.
On the other hand, as soon as you start intervening, you have to take out the whole physical disk for replacement, so you necessarily have to degrade both arrays at some point. Also, with SSDs, it’s apparently become more common that the whole disk fails, so both arrays might be affected by such events anyway.
There is nothing to be said about the details of the process that can’t be found in typical partitioning and mdadm documentation.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0