On Wed, Jun 16, 2010 at 10:47 PM, Neil Brown <neilb@xxxxxxx> wrote: > On Mon, 14 Jun 2010 12:47:23 +0200 > Nagilum <nagilum@xxxxxxxxxxx> wrote: > >> >> ----- Message from neilb@xxxxxxx --------- >> Date: Mon, 14 Jun 2010 09:15:18 +1000 >> From: Neil Brown <neilb@xxxxxxx> >> Subject: Re: Problem re-shaping RAID6 >> To: Jérôme Poulin <jeromepoulin@xxxxxxxxx> >> Cc: linux-raid <linux-raid@xxxxxxxxxxxxxxx> >> >> >> > Thanks. >> > I fixed this bug a slightly different way >> > >> > - blocks = ochunk/512 * nchunk/512 * odata * ndata / a; >> > + blocks = (ochunk/512) * (nchunk/512) * odata * ndata / a; >> > >> > >> > See >> > http://neil.brown.name/git?p=mdadm;a=commitdiff;h=200871adf9e15d5ad985f28c349fd89c386ef48a >> >> Those static numbers always make my nose wrinkle. >> Don't we have the blocksize somewhere already? I'm also concerned what >> happens when true 4k sectors are used.. >> > > A sector will always be 512 bytes to Linux, even when we have drives that can > only do IO in multiples of 8 sectors. Changing that would cause way to many > headaches. > > Yes, I could possibly use a define for '512'. Some times that is > appropriate, but I thing 512 is so clearly "bytes_per_sector" it would just > add an unnecessary level of indirection. > It is a question of taste really - no right answers. > > Thanks, > NeilBrown > > -- > 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 > Slightly off topic, but wouldn't an 'always' like that be a valid reason for starting a 2.7 or 3.0 branch; that is something where major sections of code would /have/ to be changed even if interfaces for other sections might remain static? -- 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
