zap (destroy) GPT and MBR data structures

 sgdisk --zap-all /dev/sdb

create largest possible new partition

 sgdisk --largest-new=1 /dev/sdb

check partition table integrity

 sgdisk --verify /dev/sdb

print partition table

 sgdisk --print /dev/sdb

Is this a mis-paste? I can't quite see why it is here?

jasonwryan (talk) 00:36, 19 July 2013 (UTC)

This is here because it's how I prepare hard-drives before setting them up for RAID. Not everyone uses GPT *yet* so didn't want to just stick it on the main page.. ~ AskApache (talk) 09:26, 3 October 2013 (UTC)

This is nice, especially if you want to script partitioning in a more readable way than piping input into fdisk or gdisk. --Nearwood (talk) 18:16, 15 March 2017 (UTC)

It's useful to use sfdisk -d /dev/sda | sfdisk /dev/sdb for copy the partition from one of the disks of the raid to the replacing disk. External references: http://www.howtoforge.com/replacing_hard_disks_in_a_raid1_array. If you don't use sfdisk, then you could receive the error: mdadm: /dev/sdb1 not large enough to join array —This unsigned comment is by Xan (talk) 8 November 2014. Please sign your posts with ~~~~!

In order to maintain fail-safety in the event of an interruption, a backup file should be created with

--backup-file location

We shouldn't tell people to add a drive without it.

—This unsigned comment is by Orbita (talk) 01:14, 24 August 2019 (UTC). Please sign your posts with ~~~~!

on "7.2 Track IO with iotop"

the command (bellow) to show IO from raid threads will not show IO from raid check.

# iotop -a $(sed 's/^/-p /g' <<<`pgrep "_raid|_resync|jbd2"`)

e.g.

Total DISK READ : 0.00 B/s | Total DISK WRITE : 0.00 B/s
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 8.98 K/s
 TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 
 628 be/3 root 0.00 B 0.00 B ?unavailable? [jbd2/dm-0-8]
 646 be/3 root 0.00 B 0.00 B ?unavailable? [jbd2/sdd1-8]
 16462 be/4 root 0.00 B 0.00 B ?unavailable? [md127_raid1]
 16784 be/4 root 0.00 B 0.00 B ?unavailable? [md127_resync]

# cat /proc/mdstat 
Personalities : [raid1] 
md127 : active raid1 sdc1[0] sdb1[1]
 1855337472 blocks super 1.2 [2/2] [UU]
 [=====>...............] check = 25.5% (474552832/1855337472) finish=115.0min speed=200056K/sec
 bitmap: 0/14 pages [0KB], 65536KB chunk

Anyone know a fix there? is it even possible to catch those as well? Gcb (talk) 14:43, 19 January 2025 (UTC)

The instruction for stopping raid causes the raid to auto re-assemble in a broken state if any drive is reloaded on the kernel.

mdadm --stop /dev/mdx
fdisk /dev/sda (drive used in raid, just change a partition unrelated to the raid and write to disk)

After saving any change to fdisk (or anything else that reloads the block device on the kernel) mdadm will reassemble /dev/mdx with ONLY that one drive. It's "safe". just have to --stop and --scan and it will reassemble in full. But scary and possible dangerous if yo are not expecting it and do something else instead. Gcb (talk) 14:47, 19 January 2025 (UTC)

To my understanding, this article combines generic RAID description (introductory section, RAID levels and , Implementation) with mdadm-specific parts (Installation and all following sections).

Introductory section says "This article explains how to create and manage a software RAID array using mdadm(8).", but (IMO) that is only in "Installation" and following.

So, I propose to keep here (in RAID) everything before "Installation", and move the rest to mdadm.

— Andrei Korshikov (talk) 06:05, 28 February 2026 (UTC)