All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: Neil Brown <neilb@suse.de>
Cc: "\"Ing. Daniel Rozsnyó\"" <daniel@rozsnyo.com>,
	"Milan Broz" <mbroz@redhat.com>,
	"Marti Raudsepp" <marti@juffo.org>,
	linux-kernel@vger.kernel.org,
	"Trond Myklebust" <Trond.Myklebust@netapp.com>,
	"Andrew Morton" <akpm@linux-foundation.org>
Subject: Re: bio too big - in nested raid setup
Date: Thu, 28 Jan 2010 14:07:31 +0200	[thread overview]
Message-ID: <4B617E03.1050403@panasas.com> (raw)
In-Reply-To: <20100128215015.0e0ed3a8@notabene>

On 01/28/2010 12:50 PM, Neil Brown wrote:
> 
> Both raid0 and linear register a 'bvec_mergeable' function (or whatever it is
> called today).
> This allows for the fact that these devices have restrictions that cannot be
> expressed simply with request sizes.  In particular they only handle requests
> that don't cross a chunk boundary.
> 
> As raid1 never calls the bvec_mergeable function of it's components (it would
> be very hard to get that to work reliably, maybe impossible), it treats any
> device with a bvec_mergeable function as though the max_sectors were one page.
> This is because the interface guarantees that a one page request will always
> be handled.
> 

I'm also guilty of doing some mirror work, in exofs, over osd objects.

I was thinking about that reliability problem with mirrors, also related
to that infamous problem of coping the mirrored buffers so they do not
change while writing at the page cache level.

So what if we don't fight it? what if we just keep a journal of the mirror
unbalanced state and do not page_uptodate until the mirror is finally balanced.
Only then pages can be dropped from the cache, and journal cleared.

(Balanced-mirror-page is when a page has participated in an IO to all devices
 without being marked dirty from the get-go to the completion of IO)

I think Trond's last work with adding that un_updated-but-committed state to
pages can facilitate in doing that, though I do understand that it is a major
conceptual change to the the VFS-BLOCKS relationship in letting the block devices
participate in the pages state machine (And md keeping a journal). Sigh

??
Boaz

  reply	other threads:[~2010-01-28 12:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-24 18:49 bio too big - in nested raid setup "Ing. Daniel Rozsnyó"
2010-01-25 15:25 ` Marti Raudsepp
2010-01-25 18:27   ` Milan Broz
2010-01-28  2:28     ` Neil Brown
2010-01-28  9:24       ` "Ing. Daniel Rozsnyó"
2010-01-28 10:50         ` Neil Brown
2010-01-28 12:07           ` Boaz Harrosh [this message]
2010-01-28 22:14             ` Neil Brown
2010-01-31 15:42               ` Boaz Harrosh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B617E03.1050403@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=akpm@linux-foundation.org \
    --cc=daniel@rozsnyo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marti@juffo.org \
    --cc=mbroz@redhat.com \
    --cc=neilb@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.