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 Yes, my understanding is that chunk size is the size of area upon which
> 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?
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
>