All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heinz Mauelshagen <mauelshagen@redhat.com>
To: Joe Thornber <thornber@redhat.com>
Cc: Lars Marowsky-Bree <lmb@suse.de>,
	Linux Mailing List <linux-kernel@vger.kernel.org>,
	axboe@suse.de
Subject: Re: dm core patches
Date: Mon, 16 Feb 2004 13:17:09 +0100	[thread overview]
Message-ID: <20040216121709.GA15372@redhat.com> (raw)
In-Reply-To: <20040213153936.GF15736@reti>

On Fri, Feb 13, 2004 at 03:39:36PM +0000, Joe Thornber wrote:
> On Fri, Feb 13, 2004 at 04:12:14PM +0100, Lars Marowsky-Bree wrote:
> > On 2004-02-12T20:13:40,
> >    Joe Thornber <thornber@redhat.com> said:
> > 
> > > I think the main concern now is over the testing of paths.  Sending an
> > > io down an inactive path can be very expensive for some hardware
> > > configurations.  So I'm considering changing a couple of things:
> > > 
> > > - Only ever send io to 1 priority group at a time (even test ios).
> > >   To test the lower priority groups we'd have to periodically switch to
> > >   them and use them for a bit for both test io and proper io.
> > 
> > You are missing the obvious answer:
> > 
> > - Periodically checking paths is a user-space issue and doesn't belong
> >   into the kernel. User-space gets to handle this policy.
> 
> Yes, that is obvious, I had wanted to do failback automatically.  But
> pushing it to userland does allow people to write hardware specific
> tests.  I'll try it and see what people think.

Right, such policy belongs to userpsace it seems.

The reason why I put it into the multipath target is to cover the case,
where all paths are inoperational, the system is OOM _and_ the only
chance to recover from that is the hope to unfail a path in order to
release memory preasure.

'Sorry, userspace test handler can't run, your enterprise server
is a pile of sh..' is not acceptable in case there's a path we
could unfail IMO.

Regards,
Heinz    -- The LVM Guy --


> 
> Thanks,
> 
> - Joe
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Red Hat, Inc.
Consulting Development Engineer                   Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@RedHat.com                            +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  parent reply	other threads:[~2004-02-16 12:17 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-10 16:35 dm core patches Joe Thornber
2004-02-10 16:57 ` [Patch 1/10] dm: Export dm_vcalloc() Joe Thornber
2004-02-10 16:59 ` [Patch 2/10] dm: Lift to_bytes() and to_sectors() into dm.h Joe Thornber
2004-02-10 16:59 ` [Patch 3/10] dm: Get rid of struct dm_deferred_io in dm.c Joe Thornber
2004-02-10 17:33   ` Christophe Saout
2004-02-10 17:00 ` [Patch 4/10] dm: Maintain ordering when deferring bios Joe Thornber
2004-02-10 17:00 ` [Patch 5/10] dm: Tidy up the error path for alloc_dev() Joe Thornber
2004-02-10 17:01 ` [Patch 6/10] dm: block size bug with 64 bit devs Joe Thornber
2004-02-10 17:01 ` [Patch 7/10] dm: Correct GFP flag in dm_table_create() Joe Thornber
2004-02-10 17:02 ` [Patch 8/10] dm: Zero size target sanity check Joe Thornber
2004-02-10 17:02 ` [Patch 9/10] dm: Remove redundant spin lock in dec_pending() Joe Thornber
2004-02-10 17:03 ` [Patch 10/10] dm: drop BIO_SEG_VALID bit Joe Thornber
2004-02-11 10:16 ` dm core patches Lars Marowsky-Bree
2004-02-11 10:35   ` Joe Thornber
2004-02-12 18:51     ` Lars Marowsky-Bree
2004-02-12 20:13       ` Joe Thornber
2004-02-13 15:12         ` Lars Marowsky-Bree
2004-02-13 15:39           ` Joe Thornber
2004-02-13 16:08             ` Arjan van de Ven
2004-02-16  8:19               ` Lars Marowsky-Bree
2004-02-16  9:35                 ` Arjan van de Ven
2004-02-13 23:46             ` Mike Anderson
2004-02-16 12:17             ` Heinz Mauelshagen [this message]
2004-02-13 16:03           ` Jens Axboe
  -- strict thread matches above, loose matches on Subject: below --
2004-02-13 16:44 James Bottomley
2004-02-16  8:22 ` Lars Marowsky-Bree
2004-02-16 16:57 ` Jens Axboe
2004-02-16 17:04   ` James Bottomley
2004-02-19  0:26 ` Mike Christie
2004-02-19  3:40   ` Jeff Garzik

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=20040216121709.GA15372@redhat.com \
    --to=mauelshagen@redhat.com \
    --cc=axboe@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lmb@suse.de \
    --cc=thornber@redhat.com \
    /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.