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

[NeilBrown <neilb@suse.de>]

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