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
next prev 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.