Hi! Why having LSR"s chunk size 2^n limitation?

I had experience of using FreeBSD's vinum (another software RAID).
Its author, Greg Lehey, stated in vinum's manual: "... A good
guideline for stripe size is between 256 kB and 512 kB. Avoid powers
of 2, however: they tend to cause all superblocks to be placed on the
first subdisk. ..."

Meanwhile, with LSR we're given exactly 2^n choices, for e. g.,
neither 768 KiB, nor 387 KiB won't go: "mdadm: invalid chunk/rounding
value: 387".

So, why... ($Subj) and how complex would it be to abolish this
restriction? I think this could be a key to performance increase.

P. S. Thanks a ton for LSR, Neil, BTW. :-)

--
End of message. Next message?
--
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

Re: Hi! Why having LSR"s chunk size 2^n limitation?

performace increase=3D
good algorithm for minimal read/write time
+high speed disks (latency and read / write
time/unit(bit,byte,page), latency =3D time to head position at the righ=
t
sector, cilinder, etc etc, read/write speed =3D time to read/write a
block of bits/bytes/pages)
+ fast filesystem (without many writes like journaling... but
it=B4s not crash safe....)
+ faster memory caches (for read we could cache information that
don=B4t change... if it change on next read it will be cached)

see that:
filesystem is a upper level (not device level)
cache is a under level (operational system level, maybe raid cache,
maybe filesystem cache, maybe another cache)
high speed disk (a physical level)
algorithm (the raid level)

we could implement raid at filesystem (ok it=B4s not mdadm)... (brtfs i=
f
i=B4m not wrong, and fuse raid system (a userspace raid software using
diferent filesystems))
since we want speed, get it closer to hardware (device) like md linux d=
o
better than it just a dedicated hardware (faster than your cpu+memory+l=
inux)

the problems are: more secure (file system/checksums/jornaling) =3D mor=
e
writes, more writes =3D more i/o, more i/o =3D more reads/writes =3D le=
ss
usefull information (file).
got?



2011/1/18 Igor Podlesny :
> =A0 I had experience of using FreeBSD's vinum (another software RAID)=

> Its author, Greg Lehey, stated in vinum's manual: "... A good
> guideline for stripe size is between 256 kB and 512 kB. =A0Avoid powe=
rs
> of 2, however: they tend to cause all superblocks to be placed on the
> first subdisk. ..."
>
> =A0 Meanwhile, with LSR we're given exactly 2^n choices, for e. g.,
> neither 768 KiB, nor 387 KiB won't go: "mdadm: invalid chunk/rounding
> value: 387".
>
> =A0 So, why... ($Subj) and how complex would it be to abolish this
> restriction? I think this could be a key to performance increase.
>
> =A0 P. S. Thanks a ton for LSR, Neil, BTW. :-)
>
> --
> End of message. Next message?
> --
> 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 =A0http://vger.kernel.org/majordomo-info.html
>



--=20
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Hi! Why having LSR"s chunk size 2^n limitation?

start at make you hardware faster with your linux
after
make your device faster with your filesystem (xfs, reiserfs, ext4???)
after
make you application faster with your filesystem (for mysql: myisam
with fixed table type is faster than dynamic table type and faster
than aria(mariadb) page table type)


2011/1/18 Roberto Spadim :
> performace increase=3D
> =A0 =A0 good algorithm for minimal read/write time
> =A0 =A0 +high speed disks (latency and read / write
> time/unit(bit,byte,page), latency =3D time to head position at the ri=
ght
> sector, cilinder, etc etc, read/write speed =3D time to read/write a
> block of bits/bytes/pages)
> =A0 =A0 + fast filesystem (without many writes like journaling... but
> it=B4s not crash safe....)
> =A0 =A0 + faster memory caches (for read we could cache information t=
hat
> don=B4t change... if it change on next read it will be cached)
>
> see that:
> filesystem is a upper level (not device level)
> cache is a under level (operational system level, maybe raid cache,
> maybe filesystem cache, maybe another cache)
> high speed disk (a physical level)
> algorithm (the raid level)
>
> we could implement raid at filesystem (ok it=B4s not mdadm)... (brtfs=
if
> i=B4m not wrong, and fuse raid system (a userspace raid software usin=
g
> diferent filesystems))
> since we want speed, get it closer to hardware (device) like md linux=
do
> better than it just a dedicated hardware (faster than your cpu+memory=
+linux)
>
> the problems are: more secure (file system/checksums/jornaling) =3D m=
ore
> writes, more writes =3D more i/o, more i/o =3D more reads/writes =3D =
less
> usefull information (file).
> got?
>
>
>
> 2011/1/18 Igor Podlesny :
>> =A0 I had experience of using FreeBSD's vinum (another software RAID=
).
>> Its author, Greg Lehey, stated in vinum's manual: "... A good
>> guideline for stripe size is between 256 kB and 512 kB. =A0Avoid pow=
ers
>> of 2, however: they tend to cause all superblocks to be placed on th=
e
>> first subdisk. ..."
>>
>> =A0 Meanwhile, with LSR we're given exactly 2^n choices, for e. g.,
>> neither 768 KiB, nor 387 KiB won't go: "mdadm: invalid chunk/roundin=
g
>> value: 387".
>>
>> =A0 So, why... ($Subj) and how complex would it be to abolish this
>> restriction? I think this could be a key to performance increase.
>>
>> =A0 P. S. Thanks a ton for LSR, Neil, BTW. :-)
>>
>> --
>> End of message. Next message?
>> --
>> 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 =A0http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> --
> Roberto Spadim
> Spadim Technology / SPAEmpresarial
>



--=20
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Hi! Why having LSR"s chunk size 2^n limitation?

On 18 January 2011 23:48, Roberto Spadim wrote:
> start at make you hardware faster with your linux
> after
> make your device faster with your filesystem (xfs, reiserfs, ext4???)
> after
> make you application faster with your filesystem (for mysql: myisam
> with fixed table type is faster than dynamic table type and faster
> than aria(mariadb) page table type)

Roberto, thanks, but did I ask your advices?

--
End of message. Next message?
--
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

Re: Hi! Why having LSR"s chunk size 2^n limitation?

no, but....
you talk about a filesystem - device (md raid) feature
maybe you could get better performace configuring a different
filesystem, or another hard disk or flash memories, or another raid
configuration (1+0, 0 +1, 10, 0+5,0+6, 1+5, 1+6, x+y)

check source, round is for a easier (faster maybe less complex) code.


2011/1/18 Igor Podlesny :
> On 18 January 2011 23:48, Roberto Spadim wrot=
e:
>> start at make you hardware faster with your linux
>> after
>> make your device faster with your filesystem (xfs, reiserfs, ext4???=
)
>> after
>> make you application faster with your filesystem (for mysql: myisam
>> with fixed table type is faster than dynamic table type and faster
>> than aria(mariadb) page table type)
>
> =A0 Roberto, thanks, but did I ask your advices?
>
> --
> End of message. Next message?
> --
> 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 =A0http://vger.kernel.org/majordomo-info.html
>



--=20
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Hi! Why having LSR"s chunk size 2^n limitation?

filesystem could be another software that use devices (mysql innodb
engine, a oracle database direct at device level, a logical volume
manager...)

2011/1/18 Roberto Spadim :
> no, but....
> you talk about a filesystem - device (md raid) feature
> maybe you could get better performace configuring a different
> filesystem, or another hard disk or flash memories, or another raid
> configuration (1+0, 0 +1, 10, 0+5,0+6, 1+5, 1+6, x+y)
>
> check source, round is for a easier (faster maybe less complex) code.
>
>
> 2011/1/18 Igor Podlesny :
>> On 18 January 2011 23:48, Roberto Spadim wro=
te:
>>> start at make you hardware faster with your linux
>>> after
>>> make your device faster with your filesystem (xfs, reiserfs, ext4??=
?)
>>> after
>>> make you application faster with your filesystem (for mysql: myisam
>>> with fixed table type is faster than dynamic table type and faster
>>> than aria(mariadb) page table type)
>>
>> =A0 Roberto, thanks, but did I ask your advices?
>>
>> --
>> End of message. Next message?
>> --
>> 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 =A0http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> --
> Roberto Spadim
> Spadim Technology / SPAEmpresarial
>



--=20
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Hi! Why having LSR"s chunk size 2^n limitation?

On 18/01/2011 15:59, Igor Podlesny wrote:
> I had experience of using FreeBSD's vinum (another software RAID).
> Its author, Greg Lehey, stated in vinum's manual: "... A good
> guideline for stripe size is between 256 kB and 512 kB. Avoid powers
> of 2, however: they tend to cause all superblocks to be placed on the
> first subdisk. ..."
>
> Meanwhile, with LSR we're given exactly 2^n choices, for e. g.,
> neither 768 KiB, nor 387 KiB won't go: "mdadm: invalid chunk/rounding
> value: 387".
>
> So, why... ($Subj) and how complex would it be to abolish this
> restriction? I think this could be a key to performance increase.

You're slightly confusing things. Stripe size and chunk size are
different things, but related. Stripe size = number of data discs *
chunk size. Linux software RAID does insist on a power of two chunk
size, which is almost certainly done for performance reasons, but
obviously it can't insist on a power of two stripe size, e.g. a 3-disc
RAID-0, 4-disc RAID-5 or 5-disc RAID-6 would all have 3 data discs so
the stripe size won't be a power of two.

Secondly, as far as I know all Linux filesystems are RAID-aware so know
how to distribute their superblocks and other metadata evenly across all
the discs, so they've already got any performance improvement that might
be had.

Cheers,

John.

--
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

Re: Hi! Why having LSR"s chunk size 2^n limitation?

maybe we could do betters read/write algorithm for devices (hard disks
/ solid state disks) for example (round robin, closer head, minimal
read/write time) that make a more optimized operation with mixed disks
array (ssd+hdd array) for raid 0,1,10,5,6,x+y

2011/1/18 John Robinson :
> On 18/01/2011 15:59, Igor Podlesny wrote:
>>
>> =A0 =A0I had experience of using FreeBSD's vinum (another software R=
AID).
>> Its author, Greg Lehey, stated in vinum's manual: "... A good
>> guideline for stripe size is between 256 kB and 512 kB. =A0Avoid pow=
ers
>> of 2, however: they tend to cause all superblocks to be placed on th=
e
>> first subdisk. ..."
>>
>> =A0 =A0Meanwhile, with LSR we're given exactly 2^n choices, for e. g=
,
>> neither 768 KiB, nor 387 KiB won't go: "mdadm: invalid chunk/roundin=
g
>> value: 387".
>>
>> =A0 =A0So, why... ($Subj) and how complex would it be to abolish thi=
s
>> restriction? I think this could be a key to performance increase.
>
> You're slightly confusing things. Stripe size and chunk size are diff=
erent
> things, but related. Stripe size =3D number of data discs * chunk siz=
e. Linux
> software RAID does insist on a power of two chunk size, which is almo=
st
> certainly done for performance reasons, but obviously it can't insist=
on a
> power of two stripe size, e.g. a 3-disc RAID-0, 4-disc RAID-5 or 5-di=
sc
> RAID-6 would all have 3 data discs so the stripe size won't be a powe=
r of
> two.
>
> Secondly, as far as I know all Linux filesystems are RAID-aware so kn=
ow how
> to distribute their superblocks and other metadata evenly across all =
the
> discs, so they've already got any performance improvement that might =
be had.
>
> Cheers,
>
> John.
>
> --
> 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 =A0http://vger.kernel.org/majordomo-info.html
>



--=20
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Hi! Why having LSR"s chunk size 2^n limitation?

On 19 January 2011 00:11, John Robinson wrote:
> On 18/01/2011 15:59, Igor Podlesny wrote:
[...]
> You're slightly confusing things. Stripe size and chunk size are different
> things, but related. Stripe size = number of data discs * chunk size. Linux
[...]

Am I? Take a look
http://www.freebsd.org/cgi/man.cgi?query=vinum&apropos=0&sek tion=0&manpath=FreeBSD+4.9-RELEASE&format=html
Also man mkfs.xfs is recommended too.

(I wonder how would ya imagine 4k stripe sized RAID-5. Really worth
looking at. :-)

> Secondly, as far as I know all Linux filesystems are RAID-aware so know how

You're mistaken. There're too many are not. Also, don't forget
LVM-2 in middle.

> to distribute their superblocks and other metadata evenly across all the
> discs, so they've already got any performance improvement that might be had.
>
> Cheers,
>
> John.

P. S. I think now everyone can see why this letter was
intentionally addressed to the author of LSR, not to the list.

--
End of message. Next message?
--
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

Re: Hi! Why having LSR"s chunk size 2^n limitation?

On 18/01/2011 17:23, Igor Podlesny wrote:
> On 19 January 2011 00:11, John Robinson wrote:
>> On 18/01/2011 15:59, Igor Podlesny wrote:
> [...]
>> You're slightly confusing things. Stripe size and chunk size are different
>> things, but related. Stripe size = number of data discs * chunk size. Linux
> [...]
>
> Am I? Take a look
> http://www.freebsd.org/cgi/man.cgi?query=vinum&apropos=0&sek tion=0&manpath=FreeBSD+4.9-RELEASE&format=html

Why should I be reading FreeBSD man pages when this is a Linux list? I
am using the terms stripe size and chunk size in the sense I understand
them, which is I believe the Linux sense. If you and FreeBSD choose to
use the terms differently, so be it, but please don't pull me up about
my use of terms when you're the one using the wrong ones in this context.

[...]
>> Secondly, as far as I know all Linux filesystems are RAID-aware so know how
>
> You're mistaken. There're too many are not.

I'll concede, only all the major filesystems you'd ever use in a
production environment.

> Also, don't forget
> LVM-2 in middle.

Not a problem, the same mechanisms by which filesystems can be aware of
RAID means filesystems are aware of LVM and LVM is aware of RAID.

> P. S. I think now everyone can see why this letter was
> intentionally addressed to the author of LSR, not to the list.

There's absolutely no need for that. Please leave, and take your
condescension, ignorance and offensiveness with you.

Cheers,

John.
--
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

Re: Hi! Why having LSR"s chunk size 2^n limitation?

On 19 January 2011 01:05, John Robinson > wrote:
> On 18/01/2011 17:23, Igor Podlesny wrote:
[...]
>>    Am I? Take a look
>>
>> http://www.freebsd.org/cgi/man.cgi?query=3Dvinum&apropos=3D0 &sektion=
=3D0&manpath=3DFreeBSD+4.9-RELEASE&format=3Dhtml
>
> Why should I be reading FreeBSD man pages when this is a Linux list? =
I am
> using the terms stripe size and chunk size in the sense I understand =
them,
> which is I believe the Linux sense. If you and FreeBSD choose to use =
the

Have you ever configured any "hardware" controller? Have seen words
"stripe size" there?
(You can give no answer, of course.)

> terms differently, so be it, but please don't pull me up about my use=
of
> terms when you're the one using the wrong ones in this context.
> [...]
>>>
>>> Secondly, as far as I know all Linux filesystems are RAID-aware so =
know
>>> how
>>
>>    You're mistaken. There're too many are not.
>
> I'll concede, only all the major filesystems you'd ever use in a prod=
uction
> environment.

I don't care what you think is ready for production and what is
not. There're people who still think that Linux isn't production
ready. (Though I don't care either.)
>
[...]
>
>>    P. S. I think now everyone can see why this letter was
>> intentionally addressed to the author of LSR, not to the list.
>
> There's absolutely no need for that. Please leave, and take your
> condescension, ignorance and offensiveness with you.

So nice to see that all those words is highly related to you in the
first place: "Why should I read man from freebsd", "I use terms in the
sense I understand them". Hey, what a stupidity, dare I ask? :-)

John Robinson, I didn't ask you to peek your nose into this
conversation. Calm down, take a rest. You can take a look at manual of
your mailer to ignore mails from people you don't wanna read. Don't
ask me why you should read man(s). And just before jumping in with a
nonsense like "You're slightly confusing things", please make a
favour: RTFM.

--=20
End of message. Next message?
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Hi! Why having LSR"s chunk size 2^n limitation?

thinking about performace, and rewrite the first question....
could we optimize something (at raid software) about chunck, blocks
and other thinks (used at filesystem space, not lvm or database direct
device access)?
ok... they should adjust the code to our raid source...
we can propose some tweaks for especific filesystems?
ok, who developed filesystems should make especific benchmarks....

again... could we implement some optimization for the first question?
thanks

2011/1/18 Igor Podlesny :
> On 19 January 2011 01:05, John Robinson uk> wrote:
>> On 18/01/2011 17:23, Igor Podlesny wrote:
> [...]
>>> =A0 =A0Am I? Take a look
>>>
>>> http://www.freebsd.org/cgi/man.cgi?query=3Dvinum&apropos=3D0 &sektio=
n=3D0&manpath=3DFreeBSD+4.9-RELEASE&format=3Dhtml
>>
>> Why should I be reading FreeBSD man pages when this is a Linux list?=
I am
>> using the terms stripe size and chunk size in the sense I understand=
them,
>> which is I believe the Linux sense. If you and FreeBSD choose to use=
the
>
> =A0 Have you ever configured any "hardware" controller? Have seen wor=
ds
> "stripe size" there?
> =A0 (You can give no answer, of course.)
>
>> terms differently, so be it, but please don't pull me up about my us=
e of
>> terms when you're the one using the wrong ones in this context.
>> [...]
>>>>
>>>> Secondly, as far as I know all Linux filesystems are RAID-aware so=
know
>>>> how
>>>
>>> =A0 =A0You're mistaken. There're too many are not.
>>
>> I'll concede, only all the major filesystems you'd ever use in a pro=
duction
>> environment.
>
> =A0 I don't care what you think is ready for production and what is
> not. There're people who still think that Linux isn't production
> ready. (Though I don't care either.)
>>
> [...]
>>
>>> =A0 =A0P. S. I think now everyone can see why this letter was
>>> intentionally addressed to the author of LSR, not to the list.
>>
>> There's absolutely no need for that. Please leave, and take your
>> condescension, ignorance and offensiveness with you.
>
> =A0 So nice to see that all those words is highly related to you in t=
he
> first place: "Why should I read man from freebsd", "I use terms in th=
e
> sense I understand them". Hey, what a stupidity, dare I ask? :-)
>
> =A0 John Robinson, I didn't ask you to peek your nose into this
> conversation. Calm down, take a rest. You can take a look at manual o=
f
> your mailer to ignore mails from people you don't wanna read. Don't
> ask me why you should read man(s). And just before jumping in with a
> nonsense like "You're slightly confusing things", please make a
> favour: RTFM.
>
> --
> End of message. Next message?
> --
> 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 =A0http://vger.kernel.org/majordomo-info.html
>



--=20
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Hi! Why having LSR"s chunk size 2^n limitation?

On Tue, 18 Jan 2011 22:59:07 +0700 Igor Podlesny
wrote:

> I had experience of using FreeBSD's vinum (another software RAID).
> Its author, Greg Lehey, stated in vinum's manual: "... A good
> guideline for stripe size is between 256 kB and 512 kB. Avoid powers
> of 2, however: they tend to cause all superblocks to be placed on the
> first subdisk. ..."
>
> Meanwhile, with LSR we're given exactly 2^n choices, for e. g.,
> neither 768 KiB, nor 387 KiB won't go: "mdadm: invalid chunk/rounding
> value: 387".
>
> So, why... ($Subj) and how complex would it be to abolish this
> restriction? I think this could be a key to performance increase.
>
> P. S. Thanks a ton for LSR, Neil, BTW. :-)
>

1/ The rationale given by Greg for non-power-of-two chunk sizes is not so
relevant for Linux I think. The more common filesystems can be told that
the device is a RAID and can deliberately offset the extra super blocks so
they don't all end up on the one device.

2/ Power-off-two is required simply because it was easier to code. The
restriction was dropped for RAID0 a year or more ago. The restriction
could be dropped for RAID4/5/6 and RAID10 relatively easily. It would just
require a thorough code review and changing a few 'mask' and 'shift'
operations to divisions.

3/ You are welcome.

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

Re: Hi! Why having LSR"s chunk size 2^n limitation?

2)
If we have a filesystem + logical volume manager over raid device,
this could make less CPU/IO use
if we don=B4t have a filesystem, this could make less CPU/IO use

the question is, this really make more performace?
we don=B4t know, must benchmark with each filesystem, logical volume, d=
evice....
this is a good 'feature', but i don=B4t think we will get more
performace... (any benchmark to confirm it?)


2011/1/18 NeilBrown :
> On Tue, 18 Jan 2011 22:59:07 +0700 Igor Podlesny il.com>
> wrote:
>
>> =A0 =A0I had experience of using FreeBSD's vinum (another software R=
AID).
>> Its author, Greg Lehey, stated in vinum's manual: "... A good
>> guideline for stripe size is between 256 kB and 512 kB. =A0Avoid pow=
ers
>> of 2, however: they tend to cause all superblocks to be placed on th=
e
>> first subdisk. ..."
>>
>> =A0 =A0Meanwhile, with LSR we're given exactly 2^n choices, for e. g=
,
>> neither 768 KiB, nor 387 KiB won't go: "mdadm: invalid chunk/roundin=
g
>> value: 387".
>>
>> =A0 =A0So, why... ($Subj) and how complex would it be to abolish thi=
s
>> restriction? I think this could be a key to performance increase.
>>
>> =A0 =A0P. S. Thanks a ton for LSR, Neil, BTW. :-)
>>
>
> 1/ The rationale given by Greg for non-power-of-two chunk sizes is no=
t so
> =A0relevant for Linux I think. =A0The more common filesystems =A0can =
be told that
> =A0the device is a RAID and can deliberately offset the extra super b=
locks so
> =A0they don't all end up on the one device.
>
> 2/ Power-off-two is required simply because it was easier to code. =A0=
The
> =A0restriction was dropped for RAID0 a year or more ago. =A0The restr=
iction
> =A0could be dropped for RAID4/5/6 and RAID10 relatively easily. =A0It=
would just
> =A0require a thorough code review and changing a few 'mask' and 'shif=
t'
> =A0operations to divisions.
>
> 3/ You are welcome.
>
> 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 =A0http://vger.kernel.org/majordomo-info.html
>



--=20
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Hi! Why having LSR"s chunk size 2^n limitation?

On 19 January 2011 02:44, NeilBrown wrote:
> On Tue, 18 Jan 2011 22:59:07 +0700 Igor Podlesny il.com>
> wrote:

Hi Neil! Thanks for your reply.

> 1/ The rationale given by Greg for non-power-of-two chunk sizes is no=
t so
>  relevant for Linux I think.  The more common filesystems =C2=
=A0can be told that
>  the device is a RAID and can deliberately offset the extra supe=
r blocks so
>  they don't all end up on the one device.

Yeah, that's right. But "non-2^n"-stripe is simpler in general and
wouldn't require any additional "tuning" and hopes, that FS'
developers took into consideration such things as possible RAID below
=46S- or even FS/LVM-2-layer. Shorter speaking, it would give benefits
in a much more simpler way. Also, there's another problem with "2^n":
stripe size are "gaped" more and more: 512, 1024, 2048, 4096. I'd
rather try using something like 768, 1355, 1719. Unable at present
though...
>
> 2/ Power-off-two is required simply because it was easier to code. =C2=
=A0The

I guessed that. :-)

>  restriction was dropped for RAID0 a year or more ago.  The=
restriction
>  could be dropped for RAID4/5/6 and RAID10 relatively easily. =C2=
=A0It would just
>  require a thorough code review and changing a few 'mask' and 's=
hift'
>  operations to divisions.
[...]

Would be really great. Really!

--=20
End of message. Next message?
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Hi! Why having LSR"s chunk size 2^n limitation?

On Wed, 19 Jan 2011 14:41:10 +0700 Igor Podlesny com>
wrote:

> > =A0restriction was dropped for RAID0 a year or more ago. =A0The res=
triction
> > =A0could be dropped for RAID4/5/6 and RAID10 relatively easily. =A0=
It would just
> > =A0require a thorough code review and changing a few 'mask' and 'sh=
ift'
> > =A0operations to divisions.
> [...]
>=20
> Would be really great. Really!
>=20

I'm happy to accept patches - after reviewing them of course.

NeilBrown

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

Re: Hi! Why having LSR"s chunk size 2^n limitation?

On 19 January 2011 16:32, NeilBrown wrote:
> On Wed, 19 Jan 2011 14:41:10 +0700 Igor Podlesny il.com>
> wrote:
>
>> >  restriction was dropped for RAID0 a year or more ago.  =
The restriction
>> >  could be dropped for RAID4/5/6 and RAID10 relatively easily.=
 It would just
>> >  require a thorough code review and changing a few 'mask' and=
'shift'
>> >  operations to divisions.
>> [...]
>>
>>    Would be really great. Really!
>>
>
> I'm happy to accept patches - after reviewing them of course.

I bet you do. %-)

--=20
End of message. Next message?
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html