* Does the chunk size of RAID5 really mean the "smallest atomic" mass of data?
@ 2013-08-19 1:10 taejin1999
2013-08-19 1:33 ` NeilBrown
0 siblings, 1 reply; 2+ messages in thread
From: taejin1999 @ 2013-08-19 1:10 UTC (permalink / raw)
To: linux-raid
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?
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Does the chunk size of RAID5 really mean the "smallest atomic" mass of data?
2013-08-19 1:10 Does the chunk size of RAID5 really mean the "smallest atomic" mass of data? taejin1999
@ 2013-08-19 1:33 ` NeilBrown
0 siblings, 0 replies; 2+ messages in thread
From: NeilBrown @ 2013-08-19 1:33 UTC (permalink / raw)
To: taejin1999; +Cc: linux-raid
[-- Attachment #1: Type: text/plain, Size: 1987 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2013-08-19 1:33 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-08-19 1:10 Does the chunk size of RAID5 really mean the "smallest atomic" mass of data? taejin1999
2013-08-19 1:33 ` NeilBrown
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).