On 07/03/18 21:13, Steve Keller wrote: > I have a RAID1 array with 2 disks (/dev/sda1 and /dev/sdb1) of 2 TB > each. By running mdadm -X /dev/sda1 I see that the chunk size is 64 MB: > > # mdadm -X /dev/sda1 > Filename : /dev/sda1 > Magic : 6d746962 > Version : 4 > UUID : 300551ed:f6690dfb:1c939898:af5509c6 > Events : 2599997 > Events Cleared : 2599997 > State : OK > Chunksize : 64 MB > Daemon : 5s flush period > Write Mode : Normal > Sync Size : 1953381376 (1862.89 GiB 2000.26 GB) > Bitmap : 29807 bits (chunks), 2 dirty (0.0%) > > What exactly does the chunk sized mean? My question is how reads and > writes on an array are done. Will the kernel always read or write a > complete chunk? If so, does that mean that writing a single 4 KB > block to a file system will cause a 64 MB read, i.e one chunk, change > the 4 KB block in that chunk and write back the 64 MB chunk?
Yes, my understanding is that chunk size is the size of area upon which parity is calculated, or the size of data which is allocated before moving onto the next drive etc. My guess, though, is that there is a balance to be struck. Yes, if the chunk size is small, then there is very little write amplification. But if the chunk size is too small, then you need to wait for that chunk to pass the read-write head again, you need to be switching between sectors very often etc. With a bigger chunk, you can take better advantage of caching. These days, 64Mb is a relatively small amount to pull into a buffer, it can be pulled in, modified and rewritten virtually instantanously. There's a nice article on the effect of different chunk sizes here: http://louwrentius.com/linux-raid-level-and-chunk-size-the-benchmarks.html > > Wouldn't that mean a massive performance problem? > > Steve >
signature.asc
Description: OpenPGP digital signature
