From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joe Thornber Subject: Re: Possible bug when releasing metadata snapshot in dm-thin Date: Wed, 19 Nov 2014 12:48:07 +0000 Message-ID: <20141119124807.GA14615@debian> References: Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: device-mapper development List-Id: dm-devel.ids On Wed, Nov 19, 2014 at 05:21:52PM +0800, Teng-Feng Yang wrote: > Hi all, > > I accidentally run into this weird situation which looks like a bug to me. > This bug can be reproduced every time with the following steps. > > 1) Create a thin pool and a thin volume. > 2) Write some data to this thin volume. > 3) Reserve metadata snapshot by sending "reserve_metadata_snap" to pool. > 4) Create a snapshot for the thin volume. > 5) Release metadata snapshot by sending "release_metadata_snap" to pool > 6) Remove both the snapshot and thin volume. > > After these steps, pool blocks allocated to the thin volume are never > returned to the pool. I trace the code of releasing metadata snapshot, > and I might find the root cause of this. When reserving metadata > snapshot, we will increase the reference count of data mapping root by > 1. However, the subsequent changes to the data mapping tree will split > the data mapping tree which results in increasing reference counts of > all bottom level roots. When releasing metadata snapshot, we simply > decrease the reference count of the old data mapping root without > propagating these reference count decrements all the way down. IMHO, > maybe we should call dm_btree_del() on the old data mapping root > instead of dm_sm_dec_refcount(). Yep, that sounds likely. I'll confirm and post a patch later. Thanks, - Joe