All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gionatan Danti <g.danti@assyoma.it>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Testing ThinLVM metadata exhaustion
Date: Tue, 26 Apr 2016 09:11:53 +0200	[thread overview]
Message-ID: <571F14B9.8020706@assyoma.it> (raw)
In-Reply-To: <571DE943.40204@redhat.com>

> bugzilla.redhat.com
>
> Anyway - 6.8 will likely be your solution.
>
> Thin-provisioning is NOT supposed to be used at 'corner' cases - we
> improve them, but older version simply had more of them as there was
> always clearly communicated do not over-provision if you can't provide
> the space.
>
> Out-of-space  is not equal if you run out of your filesystem space - you
> can't expect things will continue to work nicely - the cooperation of
> block layer with filesystem and metadata resilience are continually
> improved.
>
> We have actually even seen users 'targeting' to hit full-pool as a part
> of regular work-flow - bad bad plan...
>
> Regards
>
> Zdenek

[reposting due to sender error]

Hi Zdenek,
thanks for your courtesy.

I absolutely agree with you that in no case metadata exhaustion can be 
considered part of a "regular work-flow". At the same time, I often do 
"stress test" specifically crafted to put the software/hardware in the 
worst possible condition. In this manner, should an exceptionally bad 
situation occour, I know how to deal with it.

I have another question: does this bug only happen when metadata space 
is exausted? I am asking this because searching for other peoples with 
the same error message, I read this bug report: 
http://www.redhat.com/archives/dm-devel/2014-March/msg00021.html

The bug described in the message above does not necessarily happen at 
metadata exaustion time, as confirmed here: 
https://bugzilla.kernel.org/show_bug.cgi?id=68801

I understand that these are old (2014) bugs and that were fixed in Linux 
3.14 but, using thin LVM volumes in production systems (albeit with RH 7 
only), I want to be reasonably sure that no show-stopper bug can hit me. 
Are current RH OSes (6.7 and 7.2) immune from this bug (metadata 
corruption even if tmeta is not full)?

Thanks.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8

  parent reply	other threads:[~2016-04-26  7:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-18 14:25 [linux-lvm] Testing ThinLVM metadata exhaustion Gionatan Danti
2016-04-22 13:12 ` Gionatan Danti
2016-04-22 14:04   ` Zdenek Kabelac
2016-04-23  8:40     ` Gionatan Danti
2016-04-25  8:59       ` Gionatan Danti
2016-04-25  9:54         ` Zdenek Kabelac
2016-04-25 16:52           ` Gionatan Danti
2016-04-26  7:11           ` Gionatan Danti [this message]
2016-04-27 11:11             ` Gionatan Danti
2016-05-03 10:05               ` Gionatan Danti

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=571F14B9.8020706@assyoma.it \
    --to=g.danti@assyoma.it \
    --cc=linux-lvm@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.