On Wed, 25 Feb 2015 18:40:46 -0600 Alireza Haghdoost <alireza@xxxxxxxxxx> wrote: > On Tue, Feb 24, 2015 at 12:29 AM, Markus Stockhausen > <stockhausen@xxxxxxxxxxx> wrote: > >> Von: linux-raid-owner@xxxxxxxxxxxxxxx [linux-raid-owner@xxxxxxxxxxxxxxx]" im Auftrag von "Roman Mamedov [rm@xxxxxxxxxxx] > >> Gesendet: Dienstag, 24. Februar 2015 00:58 > >> An: linux-raid@xxxxxxxxxxxxxxx > >> Betreff: RAID6 write I/O amplification? > >> > >> Hello, > >> > >> Got a bit of a "how does it actually work" question... > >> > >> Suppose I have an MD RAID6 of 8 drives, with 64KB chunk size. > >> > >> I am rewriting a 4KB filesystem sector somewhere on that RAID (not crossing > >> the stripe boundary). > >> > >> What's the amount of disk I/O in total this will result in? > >> > >> I assume the RAID will need to read data from all drives, recompute parity, > >> then write to the data stripe where the updated piece happened to be, and also > >> write to two parity stripes. > >> > >> Is this done at a stripe granularity, so 6x64KB reads, 3x64KB writes? > >> Or down to individual sectors (pages), i.e. 6x4KB reads, 3x4KB writes? > >> Or am I describing this algorithm correctly at all? > > > > Implementation will work on "internal" stripe granularity and that is 4K > > So your case will be 6x4KB read + 3x4KB write. > > Having said that, does it mean that following description of "chunk > size" is wrong: > '[chunk size] is the smallest "atomic" mass of data that can be > written to the devices' > since in this case chunk size is 64KB but 4KB is written atomically (?). > I have find it in the kernel.org wiki page [1] I think that when it says "atomic" it means in space, not time. i.e. one (properly aligned) chunk of data will not be split up and written to different devices, it will all be written to one device. If you write more than a chunk, it will be split up and parts of if written to different devices. You can still write less than a chunk. So the intent is correct I think, but the word "atomic" doesn't really convey the right meaning. Probably it should be re-written to avoid that term and just spell out what is happening. NeilBrown
Attachment:
pgpmKXD0IU4Fn.pgp
Description: OpenPGP digital signature
