I connected a 4-bay enclosure with 4 new 8TB disks to my rPi. This disks appeared in lsblk as sda to sdd. Following this tutorial I created the array doing

mdadm -C /dev/md0 --level=raid5 --raid-devices=4 /dev/sda /dev/sdb /dev/sdc /dev/sdd

The array started building itself without issue and after 2 days (!) it was done. The output of mdadm --detail /dev/md0 is as follows

   Version : 1.2
   Creation Time : Mon Nov  4 15:15:37 2019
   Raid Level : raid5
   Array Size : 23441682432 (22355.73 GiB 24004.28 GB)
   Used Dev Size : 7813894144 (7451.91 GiB 8001.43 GB)
   Raid Devices : 4
   Total Devices : 4
   Persistence : Superblock is persistent

   Intent Bitmap : Internal

   Update Time : Thu Nov  7 01:24:44 2019
   State : clean
   Active Devices : 4
   Working Devices : 4
   Failed Devices : 0
   Spare Devices : 0

    Layout : left-symmetric
    Chunk Size : 512K

    Consistency Policy : bitmap

    Name : raspberrypi:0  (local to host raspberrypi)
    UUID : 05442287:97e027c2:1ddf5e37:c16c1428
    Events : 35568

    Number   Major   Minor   RaidDevice State
      0       8        0        0      active sync   /dev/sda
      1       8       16        1      active sync   /dev/sdb
      2       8       32        2      active sync   /dev/sdc
      4       8       48        3      active sync   /dev/sdd

The output for cat /proc/mdstat is

Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdd[4] sdc[2] sdb[1] sda[0]
      23441682432 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 0/59 pages [0KB], 65536KB chunk

This is my first time using mdadm, but I can't see anything out of place in this statuses. however, when I try to do sudo mkfs.ext4 /dev/md0 I get the following error

mke2fs 1.44.5 (15-Dec-2018)
Creating filesystem with 5860420608 4k blocks and 366276608 inodes
Filesystem UUID: 30b59932-d4ca-47f9-9b58-50cb28fc579c
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
    102400000, 214990848, 512000000, 550731776, 644972544, 1934917632,
    2560000000, 3855122432, 5804752896

Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks): mkfs.ext4: Attempt to read block from filesystem
resulted in short read while trying to create journal

I'm really at a loss here, and google isn't helping either. Any ideas are greatly appreciated.

  • Not a solution to your particular problem, but the Pi isn't the best choice for hosting software RAID (the USB has gotten more reliable over the years, but there's still the risk of all four disks falling offline at once), and RAID 5 isn't a good choice for large arrays (that two-day build time you experienced is how long it'll take to recover from a failed disk, and there's a decent risk that you'll have a second failure during the rebuild).
    – Mark
    Commented Nov 7, 2019 at 2:09
  • @Mark I know, but I intend to use this disks as a dump for media files, so it's not critical than they are online 24/7 or than the array can be rebuilt in a hurry.
    – Zegpi
    Commented Nov 7, 2019 at 2:14

1 Answer 1


Ext4 is limited 16 TB on 32-bit systems.

  • I'm assuming you meant 16TB, as 16GB is smaller than my current SD card. If this is the case, that would explain everything. What should I attempt to do now? Partition the raid5? If so, how should I go about doing that? Thanks for the help!
    – Zegpi
    Commented Nov 7, 2019 at 3:32
  • @Zegpi if it's a pi4 look into a 64b os. If you want those drives encrypted buy an Odroid N2 (~10x faster). You could use striped LVM instead of mdadm, and make a few LVs. I never tested if brtfs or zfs have 32b limitations but they also stripe like mdadm. Commented Nov 8, 2019 at 2:25
  • Thi finally pointed me in the right direction, so I'm marking it as the answer. Thx!
    – Zegpi
    Commented Nov 11, 2019 at 2:49

You must log in to answer this question.

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