Hi! Is "container" more efficient in terms of I/O op. numbers ...

Hi! Is "container" more efficient in terms of I/O op. numbers ...

[Igor Podlesny]

   ... then several "stand-alone" RAIDs on the same HDDs? -- Say, when
using write intent bitmaps.

-- 
End of message. Next message?

Re: Hi! Is "container" more efficient in terms of I/O op. numbers ...

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 304 bytes --]

On Thu, 24 May 2012 23:30:54 +0800 Igor Podlesny <for.poige+linux@gmail.com>
wrote:

>    ... then several "stand-alone" RAIDs on the same HDDs? -- Say, when
> using write intent bitmaps.
> 

I'm not sure you question exactly makes sense, but the answer would be "no"
if it did :-)

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Hi! Is "container" more efficient in terms of I/O op. numbers ...

[Igor Podlesny]

On 25 May 2012 08:14, NeilBrown <neilb@suse.de> wrote:
> On Thu, 24 May 2012 23:30:54 +0800 Igor Podlesny <for.poige+linux@gmail.com>
> wrote:
>
>>    ... then several "stand-alone" RAIDs on the same HDDs? -- Say, when
>> using write intent bitmaps.
>>
>
> I'm not sure you question exactly makes sense, but the answer would be "no"
> if it did :-)

   Well, due to disks seeks are expensive, hot data locality is
preferable and valuable thing, isn't it?
   And it makes sense not only for WIB, but other frequent metadata
updates, doesn't it?

-- 
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! Is "container" more efficient in terms of I/O op. numbers ...

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]

On Fri, 25 May 2012 09:52:52 +0800 Igor Podlesny <for.poige+linux@gmail.com>
wrote:

> On 25 May 2012 08:14, NeilBrown <neilb@suse.de> wrote:
> > On Thu, 24 May 2012 23:30:54 +0800 Igor Podlesny <for.poige+linux@gmail.com>
> > wrote:
> >
> >>    ... then several "stand-alone" RAIDs on the same HDDs? -- Say, when
> >> using write intent bitmaps.
> >>
> >
> > I'm not sure you question exactly makes sense, but the answer would be "no"
> > if it did :-)
> 
>    Well, due to disks seeks are expensive, hot data locality is
> preferable and valuable thing, isn't it?
>    And it makes sense not only for WIB, but other frequent metadata
> updates, doesn't it?
> 

Thank you for fleshing out your question a bit.  It is always useful to state
your assumptions where asking a question as it makes it easier to understand
and answer the question.

The general metadata isn't updated very often - not often enough to justify
any particular concern for where it is placed.  For a 'reshape' it can be
updated more often, but that is an unusual situation.

bitmap metadata certainly can be updated often, but there is no container
format currently supported which makes use of write-intent bitmaps, so
thinking about containers for bitmaps is not relevant.

If it were, it would make sense to keep the bitmap close to the data that it
described, so having a container arrangement would not be better than
individual arrays.  It maybe be worse depending on the particular details.

Does that make sense?

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Hi! Is "container" more efficient in terms of I/O op. numbers ...

[Igor Podlesny]

On 25 May 2012 10:23, NeilBrown <neilb@suse.de> wrote:
[...]
> bitmap metadata certainly can be updated often, but there is no container
> format currently supported which makes use of write-intent bitmaps, so
> thinking about containers for bitmaps is not relevant.

   Well, can it be adopted by allocation sub-array for WIB then, for e. g.?

> If it were, it would make sense to keep the bitmap close to the data that it
> described, so having a container arrangement would not be better than
> individual arrays.  It maybe be worse depending on the particular details.

   Yep, with some kind of updates merging it could be faster, I guess.

   BTW, as it seems the most optimal location of WIB is in the middle
of corresponding datum -- thus
seeks length are always less or equal (datum length 1/2). Have you
considered this layout? :-)

> Does that make sense?

   I hope so. :)

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