3

the man page for mdadm says: "[chunk] is only meaningful for RAID0, RAID4, RAID5, RAID6, and RAID10." i.e. it does not apply for raid1. even if you pass the value, it will say ignoring chunk size and after the raid 1 is created, you get:

md1 : active raid1 ...
      4883639488 blocks super 1.2 ...
      bitmap: 0/37 pages [0KB], 65536KB chunk

For some reason it used a 65Mb for a 5.6Tb disk size. Why?

Then, the man page for mkfs.ext4 says

stride=stride-size = Configure the filesystem for a RAID array with stride-size filesystem blocks. This is the number of blocks read or written to disk before moving to the next disk, which is sometimes referred to as the chunk size. This mostly affects placement of filesystem metadata like bitmaps at mke2fs time to avoid placing them on a single disk, which can hurt performance. It may also be used by the block allocator.

stripe_width=stripe-width = Configure the filesystem for a RAID array with stripe-width filesystem blocks per stripe. This is typically stride-size * N, where N is the number of data-bearing disks in the RAID (e.g. for RAID 5 there is one parity disk, so N will be the number of disks in the array minus 1). This allows the block allocator to prevent read-modify-write of the parity in a RAID stripe if possible when the data is written.

What does all that means for RAID1? should I just repeat the same value as i got for chunk above? and ignore stripe_width as RAID1 falls out of the "if possible" note? or does it not?

It's not very clear what I am supposed to do for RAID1. using the formulas i found in other tutorials for RAID0 and RAID5, i got those numbers for my RAID1 array, which i think are NOT correct.. mkfs.ext4 -b 4096 -E stride=16384,stripe-width=16384

Improve this question

2 Answers 2

Reset to default
1

I think this sould be fine as you are not striping anything. You only need that number to tell after how much data the next disk should be used. However, you effectively have only one data disk (and one mirror of it) so the controller doesn't need to change the disk and thus it should be fine. The high number also makes sense in my opinion as the controller would only ask itself after a large chunk which disk to use. So this should limit the overhead.

Improve this answer
1
  • what about the stripe part? i still have two+ disks as data-bearing to use the man page terms.
    – gcb
    Commented May 19, 2023 at 5:11
1

RAID1 is effectively the same as a single disk so there is no RAID optimisation to be had, but there are still ways of optimising your file system metadata locations based on your application's I/O profile and possibly the underlying disk's abilities (e.g. SSD erase block size). I wrote an article on this exact subject a while back, explaining why file system alignment matters, which you may find useful.

Improve this answer
4
  • excellent article! one question... you mention stripe-width= is only taking one disk into account while the manual I quote above says blocks * data-bearing disks. Why did you chose N=1 if your raid0 all disks hold data?
    – gcb
    Commented May 19, 2023 at 5:18
  • 1
    @gcb because we want the file system to treat each of the two disks as self contained. We don't want a data update on one to trigger a metadate on the other and waste an iop from each instead of just one. This was a specific RAID0 edge case used to illustrate the point, in reality we would never use RAID0 in production.
    – Gordan Bobić
    Commented May 19, 2023 at 10:59
  • I see. So, if i value consistency, should I use N=total disks, for my raid1?
    – gcb
    Commented May 19, 2023 at 14:02
  • No, for raid1 n should be 1, same as a single disk.
    – Gordan Bobić
    Commented May 20, 2023 at 0:30

You must log in to answer this question.

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