From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kent Overstreet Subject: Re: Bcache version 9 Date: Tue, 23 Nov 2010 22:25:21 -0800 Message-ID: <4CECAFD1.10506@gmail.com> References: <20101121140808.GA6429@moria> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-bcache@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org To: =?ISO-8859-1?Q?C=E9dric_Villemain?= Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On 11/23/2010 03:35 PM, C=E9dric Villemain wrote: > First I am really happy to see this project appearing here. > > 2010/11/21 Kent Overstreet: >> Bcache is a patch to use SSDs to transparently cache arbitrary block >> devices. Its main claim to fame is that it's designed for the >> performance characteristics of SSDs - it avoids random writes and >> extraneous IO at all costs, instead allocating buckets sized to your >> erase blocks and filling them up seqentially. It uses a hybrid >> btree/log, instead of a hash table as some other caches. > > Is it its main diff with flashcache ? > https://github.com/facebook/flashcache/blob/master/doc/flashcache-doc= =2Etxt Yeah. It's a more complex approach, but it's capable of significantly=20 higher performance. Performance has regressed some lately (I've been=20 concentrating on other things and don't really have the hardware for=20 performance work), but a month or so ago it was benchmarking around 50%= =20 higher than flashcache, with mysql on an X25-E. > >> >> It does both writethrough and writeback caching - it can use most of >> your SSD for buffering random writes, which are then flushed >> sequentially to the backing device. Skips sequential IO, too. >> >> Current status: >> Recovering from unclean shutdown has been the main focus, and is now >> working magnificantly - I'm having no luck breaking it. This version >> looks to be plenty safe enough for beta testing (still, make backups= ). >> >> Proper discard support is in and enabled by default; bcache won't ev= er >> write to the same location twice without issuing a discard to that >> bucket. > > Is it relative to Torn Page possible issue outline by flashcache de= vel ? Kind of. Bcache isn't subject to that issue, but that's because bcache=20 is cow and always strictly orders writes.