All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takahiro Yasui <tyasui@redhat.com>
To: lvm-devel@redhat.com
Subject: [RFC PATCH] Reduce noise about missing devices.
Date: Thu, 06 May 2010 19:42:47 -0400	[thread overview]
Message-ID: <4BE353F7.3040305@redhat.com> (raw)
In-Reply-To: <20100505190119.GF27027@agk-dp.fab.redhat.com>

On 05/05/10 15:01, Alasdair G Kergon wrote:
> On Tue, Apr 27, 2010 at 11:32:06PM +0200, Peter Rockai wrote:
>> this is not intended to be directly applied, but more to start a
>> discussion. One problem with our handling of missing devices is the huge
>> amount of log noise each missing device produces. In a single run of
>> lvconvert --repair, I get multiple screens of "read error" and "Couldn't
>> find device with uuid"...
>  
> Well my first question before suppressing messages would be: Are all the
> repeated accesses that generate the messages actually necessary?
> Or are the messages just a symptom of other problems which should be
> addressed instead?

I checked how many times a broken device was accessed by the lvconvert
command when 'lvconvert --repair' is executed using the following lvm
environment:

  VG: 3PVs
  LV: mirror composed of 2 legs and 1 disk log

  vg00-lv00 (253:3)
   |-vg00-lv00_mimage_1 (253:2)
   |  `- (8:48)
   |-vg00-lv00_mimage_0 (253:1)
   |  `- (8:32)
   `-vg00-lv00_mlog (253:0)
      `- (8:64)

When a primary leg is broken, 'lvconvert --repair' accesses the primary
leg by '47 times.' I think what we should do is to suppress 'access to
a broken device' instead of suppressing 'displaying error messages.'

Suppress error messages might be friendly to some users, but other users
might not notice how often a broken device is accessed by the lvconvert
command.

Do we need to access a broken device so many times? If lvm commands
detects errors on a device a few times, my opinion is that lvm
commands should quit accessing the device.

Thanks,
Taka



  reply	other threads:[~2010-05-06 23:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-27 21:32 [RFC PATCH] Reduce noise about missing devices Petr Rockai
2010-04-28 15:18 ` Petr Rockai
2010-05-05 19:01 ` Alasdair G Kergon
2010-05-06 23:42   ` Takahiro Yasui [this message]
2010-05-07  0:27     ` Alasdair G Kergon

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=4BE353F7.3040305@redhat.com \
    --to=tyasui@redhat.com \
    --cc=lvm-devel@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.