-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/2/2014 9:49 AM, joystick wrote: > lot of them together since it knows how much data it has to read > (via readahead, most of the times). The disk reorders read/write > requests That's the problem; if you want a 1 GB stripe size then you need 2 GB of readahead to keep the disks spinning. That's not really reasonable. The idea is to get back to ~128k being enough readahead to keep the disks busy, without causing loads of seeking. Reordering doesn't come into play here since I'm talking sequential reads. > Secondly, for writes, I suspect you are assuming that a whole stipe > has to be read and rewritten in order for one small write to be > performed, but it is not so. For a 4k write in raid5, two 4k > sectors are read, then two 4k sectors are written, and this is > completely independent from chunk size. It already behaves mostly > like your "groups", which are the stripes actually. I don't believe this is correct. raid5 caches an entire stripe at a time in the stripe cache. Even if it were so, it still wouldn't be related to what I'm talking about, which is the fact that when doing large streaming reads, the disk head has to seek to skip the redundant data. How often it has to do that is related to the chunk size, and is something you want to minimize since it is bad for throughput. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSxYSWAAoJEI5FoCIzSKrwvdoH/3/181+FZ1O40NJ1BuDan1Hc oHwvqt+B+ow2H042l0gduVM8ZkgsGaLXF2R4/g2dYF4p77OvCPiHmY5R47WdUJzI M6phlZlkCgKK3uyUCaCPAxJ2OKdzZxvlM9SDtywfH3H6aFYmAOWJTUD9EdkztRfZ XM6CGpRly3/sCx+P3RTb4X/5F2VOJlbzEar5mp1TYIlYyR4hdeDeaci32Xgtmkcv HBVAXnNMfQew4fTEQzD+hE1/ILIVB0xZt5E/O5368pidcTU7ndPVjXywWA9FF/CL ckQSnNE2DpLXEb/2uT3VsAqEcJjMXYspGs1qocGw7VOMirM7ZstREX/kphJdPAU= =eVT+ -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
