From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kent Overstreet Subject: Re: reverse link from bucket to keys Date: Tue, 16 Jul 2013 13:59:34 -0700 Message-ID: <20130716205934.GB27000@kmo-pixel> References: <20130710230257.GD13527@kmo-pixel> <20130712021057.GA30223@kmo-pixel> <20130712022551.GB30223@kmo-pixel> <20130712024125.GC30223@kmo-pixel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-bcache-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: sheng qiu Cc: linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-bcache@vger.kernel.org On Tue, Jul 16, 2013 at 11:14:29AM -0400, sheng qiu wrote: > Hi Kent, > > sorry to bother you again. i got another question. it's about the > bucket->pin. Can you explain what's the usage for this data member? > i see only bucket with pin value "0" can be invalidated. And only "0" > valued pin bucket's prio will be decreased within the > bch_rescale_priorities(). But every time when you write data to > bucket, you increase that bucket's pin, and i did not see when it will > be decreased. This makes me a little confused. Or do i miss anything > where you might reset it? It's to keep buckets from being garbage collected after they're allocated but before we've added a pointer to them to the btree. I've actually been meaning to get rid of it, and just keep a refcount on the open buckets (the ones pick_data_bucket() uses) and have garbage collection mark those buckets too. Originally I also used it for preventing buckets from being invalidated while we were reading from them (on cache hit), but I got rid of that ages ago for performance reasons - now it just checks after the read finishes if it was invalidated, and if so rereads from the backing device.