All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peri Hankey <mpah@thegreen.co.uk>
To: Wm <bill@boughton.org.uk>
Cc: xen-devel@lists.sourceforge.net
Subject: Re: A snapshot is not (really) a cow
Date: Mon, 27 Sep 2004 12:29:37 +0100	[thread overview]
Message-ID: <4157F9A1.1040302@thegreen.co.uk> (raw)
In-Reply-To: <20040927103914.GA8152@yuri.org.uk>

That looks like it.

The xen0 default kernel config used to build nbd as a module. That meant 
that there were no nbd devices available at boot or at any time until 
you explictly loaded the nbd module. So they weren't visible to the lvm 
code that scans block devices. With the nbd devices available, the lvm 
stuff starts happily scanning and rescanning all 128 of them.

So far I have managed to show this by inadvertently putting a syntax 
error in lvm.conf - my attempts to reject nb* and accept others 
continued to scan everything. But I think I'm on the right track.

Thanks
-- Peri

Wm wrote:

>On Mon, Sep 27, 2004 at 09:40:49AM +0100, Peri Hankey wrote:
>  
>
>>A further point - I mentioned in my last mail that attempts to access an 
>>nbd device start very early in the boot sequence. I now also notice 
>>after looking at several boot sequences that the first seems always to 
>>be an attempt to access nbd60, sector 0 (but the sector 0 may be a red 
>>herring).  I suspect something is trying to acccess block device 43,60 
>>hoping to find something other than a non-existent nbd device).
>>    
>>
>
>Could it be the lvm / device mapper initalistation scripts seaching for
>block devices with pvs on them?
>
>Can you have a look in /etc/lvm/lvm.conf in there you can tell
>lvm to only scan devices that you know might have pvs on them.
>
>
>bill
>
>
>  
>



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

  parent reply	other threads:[~2004-09-27 11:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-26 11:38 A snapshot is not (really) a cow Peri Hankey
2004-09-26 14:48 ` Christian Limpach
2004-09-26 19:05   ` Peri Hankey
2004-09-26 19:28     ` Ian Pratt
2004-09-26 21:29       ` Peri Hankey
2004-09-26 21:44         ` Ian Pratt
2004-09-27  7:57           ` Peri Hankey
2004-09-27 10:12             ` Ian Pratt
2004-09-27  8:40           ` Peri Hankey
     [not found]             ` <20040927103914.GA8152@yuri.org.uk>
2004-09-27 11:29               ` Peri Hankey [this message]
2004-09-27 13:35   ` Peri Hankey
2004-09-27 17:21     ` Christian Limpach

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=4157F9A1.1040302@thegreen.co.uk \
    --to=mpah@thegreen.co.uk \
    --cc=bill@boughton.org.uk \
    --cc=xen-devel@lists.sourceforge.net \
    /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.