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

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

[Igor Podlesny]

   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?

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

[Roberto Spadim]

performace increase=
     good algorithm for minimal read/write time
     +high speed disks (latency and read / write
time/unit(bit,byte,page), latency = time to head position at the right
sector, cilinder, etc etc, read/write speed = time to read/write a
block of bits/bytes/pages)
     + fast filesystem (without many writes like journaling... but
it´s not crash safe....)
     + faster memory caches (for read we could cache information that
don´t 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´s not mdadm)... (brtfs if
i´m 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 do
better than it just a dedicated hardware (faster than your cpu+memory+linux)

the problems are: more secure (file system/checksums/jornaling) = more
writes, more writes = more i/o, more i/o = more reads/writes = less
usefull information (file).
got?



2011/1/18 Igor Podlesny <for.poige+linux@gmail.com>:
>   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
>



-- 
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
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?

[Roberto Spadim]

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 <roberto@spadim.com.br>:
> performace increase=
>     good algorithm for minimal read/write time
>     +high speed disks (latency and read / write
> time/unit(bit,byte,page), latency = time to head position at the right
> sector, cilinder, etc etc, read/write speed = time to read/write a
> block of bits/bytes/pages)
>     + fast filesystem (without many writes like journaling... but
> it´s not crash safe....)
>     + faster memory caches (for read we could cache information that
> don´t 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´s not mdadm)... (brtfs if
> i´m 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 do
> better than it just a dedicated hardware (faster than your cpu+memory+linux)
>
> the problems are: more secure (file system/checksums/jornaling) = more
> writes, more writes = more i/o, more i/o = more reads/writes = less
> usefull information (file).
> got?
>
>
>
> 2011/1/18 Igor Podlesny <for.poige+linux@gmail.com>:
>>   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
>>
>
>
>
> --
> Roberto Spadim
> Spadim Technology / SPAEmpresarial
>



-- 
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
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?

[Igor Podlesny]

On 18 January 2011 23:48, Roberto Spadim <roberto@spadim.com.br> 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?

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

[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 <for.poige+linux@gmail.com>:
> On 18 January 2011 23:48, Roberto Spadim <roberto@spadim.com.br> 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
>



-- 
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
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?

[Roberto Spadim]

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 <roberto@spadim.com.br>:
> 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 <for.poige+linux@gmail.com>:
>> On 18 January 2011 23:48, Roberto Spadim <roberto@spadim.com.br> 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
>>
>
>
>
> --
> Roberto Spadim
> Spadim Technology / SPAEmpresarial
>



-- 
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
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?

[John Robinson]

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.

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

[Roberto Spadim]

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 <john.robinson@anonymous.org.uk>:
> 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
>



-- 
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
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?

[Igor Podlesny]

On 19 January 2011 00:11, John Robinson <john.robinson@anonymous.org.uk> 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&sektion=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?

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

[John Robinson]

On 18/01/2011 17:23, Igor Podlesny wrote:
> On 19 January 2011 00:11, John Robinson<john.robinson@anonymous.org.uk>  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&sektion=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.

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

[Igor Podlesny]

On 19 January 2011 01:05, John Robinson <john.robinson@anonymous.org.uk> wrote:
> On 18/01/2011 17:23, Igor Podlesny wrote:
[...]
>>    Am I? Take a look
>>
>> http://www.freebsd.org/cgi/man.cgi?query=vinum&apropos=0&sektion=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

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

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

[Roberto Spadim]

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 <for.poige+linux@gmail.com>:
> On 19 January 2011 01:05, John Robinson <john.robinson@anonymous.org.uk> wrote:
>> On 18/01/2011 17:23, Igor Podlesny wrote:
> [...]
>>>    Am I? Take a look
>>>
>>> http://www.freebsd.org/cgi/man.cgi?query=vinum&apropos=0&sektion=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
>
>   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 production
>> 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.
>
> --
> 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
>



-- 
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
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?

[NeilBrown]

On Tue, 18 Jan 2011 22:59:07 +0700 Igor Podlesny <for.poige+linux@gmail.com>
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

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

[Roberto Spadim]

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

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


2011/1/18 NeilBrown <neilb@suse.de>:
> On Tue, 18 Jan 2011 22:59:07 +0700 Igor Podlesny <for.poige+linux@gmail.com>
> 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
>



-- 
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
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?

[Igor Podlesny]

On 19 January 2011 02:44, NeilBrown <neilb@suse.de> wrote:
> On Tue, 18 Jan 2011 22:59:07 +0700 Igor Podlesny <for.poige+linux@gmail.com>
> wrote:

   Hi Neil! Thanks for your reply.

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

   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
FS- 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.  The

   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.  It would just
>  require a thorough code review and changing a few 'mask' and 'shift'
>  operations to divisions.
[...]

   Would be really great. Really!

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

[NeilBrown]

On Wed, 19 Jan 2011 14:41:10 +0700 Igor Podlesny <for.poige+linux@gmail.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.

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?

[Igor Podlesny]

On 19 January 2011 16:32, NeilBrown <neilb@suse.de> wrote:
> On Wed, 19 Jan 2011 14:41:10 +0700 Igor Podlesny <for.poige+linux@gmail.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. %-)

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