Does the chunk size of RAID5 really mean the "smallest atomic" mass of data?

2 messages, 2 authors, 2013-08-19 · open the first message on its own page

Does the chunk size of RAID5 really mean the "smallest atomic" mass of data?

From: <hidden>
Date: 2013-08-19 01:10:18

I have counted the number of write requests from the raid disks which are
implemented as virtual block devices.
The result is
  ** the larger chunk size is, the more write requests are received per
device.

I was wondering what the "chunk size" means on RAID5 of mdadm.
According to below site, chunk is the smallest atomic mass of data that
can be written to the device.
(https://raid.wiki.kernel.org/index.php/RAID_setup)

The source code, however, seems to work differently.
As I know, mdadm issues bio to each device in ops_run_io function.
In the code, the size of bio is set to be only STRIPE_SIZE.
I think the device would get STRIPE_SIZE-sized data which is smaller than
the chunk size.

Is the chunk size not smallest data that can be written to the device?
Or is there any procedure that merge the STRIPE_SIZE-sized data into
chunk-sized data?

I am looking forward to your reply.
Thank you.

PS) Could you guess why more writes are issued for larger chunk size?

Re: Does the chunk size of RAID5 really mean the "smallest atomic" mass of data?

From: NeilBrown <hidden>
Date: 2013-08-19 01:33:49

On Mon, 19 Aug 2013 10:10:18 +0900 taejin1999@davinci.snu.ac.kr wrote:
I have counted the number of write requests from the raid disks which are
implemented as virtual block devices.
The result is
  ** the larger chunk size is, the more write requests are received per
device.
That is peculiar.  How do the sizes of the write requests compare?
I was wondering what the "chunk size" means on RAID5 of mdadm.
According to below site, chunk is the smallest atomic mass of data that
can be written to the device.
That isn't correct.
(https://raid.wiki.kernel.org/index.php/RAID_setup)
The text for chunksize for RAID5 is a little unclear, but I'm not sure how
you reached the above conclusion from it.
The source code, however, seems to work differently.
As I know, mdadm issues bio to each device in ops_run_io function.
It is "md" that issues bios etc.  "md" is the kernel driver.  "mdadm" is the
tool for ADMinistering MD arrays.
In the code, the size of bio is set to be only STRIPE_SIZE.
I think the device would get STRIPE_SIZE-sized data which is smaller than
the chunk size.
Correct.  Though the elevator might merge bios together.
Is the chunk size not smallest data that can be written to the device?
It is not
Or is there any procedure that merge the STRIPE_SIZE-sized data into
chunk-sized data?
That depends on the lower level device that received the bios from md.  It
might merge multiple bios into single requests.
I am looking forward to your reply.
Thank you.

PS) Could you guess why more writes are issued for larger chunk size?
Maybe there are more read-modify-write cycles so the parity gets updates
multiple times.

NeilBrown

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help