From mboxrd@z Thu Jan 1 00:00:00 1970 References: <1438f48b-0a6d-4fb7-92dc-3688251e0a00@assyoma.it> <58E7992A.4030000@tlinx.org> <7732cbebfc561db0d8749310f1ba010f@xenhideout.nl> From: Zdenek Kabelac Message-ID: Date: Thu, 13 Apr 2017 16:33:30 +0200 MIME-Version: 1.0 In-Reply-To: <7732cbebfc561db0d8749310f1ba010f@xenhideout.nl> Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [linux-lvm] Snapshot behavior on classic LVM vs ThinLVM Reply-To: LVM general discussion and development List-Id: LVM general discussion and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: LVM general discussion and development , Xen Dne 13.4.2017 v 15:52 Xen napsal(a): > Stuart Gathman schreef op 13-04-2017 14:59: > >> If you are going to keep snapshots around indefinitely, the thinpools >> are probably the way to go. (What happens when you fill up those? >> Hopefully it "freezes" the pool rather than losing everything.) > > My experience is that the system crashes. > > I have not tested this with a snapshot but a general thin pool overflow > crashes the system. > > Within half a minute, I think. > > It is irrelevant whether the volumes had anything to do with the operation of > the system; ie. some mounted volumes that you write to that are in no other > use will crash the system. Hello Just let's repeat. Full thin-pool is NOT in any way comparable to full filesystem. Full filesystem has ALWAYS room for its metadata - it's not pretending it's bigger - it has 'finite' space and expect this space to just BE there. Now when you have thin-pool - it cause quite a lot of trouble across number of layers. There are solvable and being fixed. But as the rule #1 still applies - do not run your thin-pool out of space - it will not always heal easily without losing date - there is not a simple straighforward way how to fix it (especially when user cannot ADD any new space he promised to have) So monitoring pool and taking action ahead in time is always superior solution to any later postmortem systems restores. Regards Zdenek