From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org ([80.91.229.3]:39417 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752857AbcE2UpY (ORCPT ); Sun, 29 May 2016 16:45:24 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1b77aL-0008Pk-Us for linux-btrfs@vger.kernel.org; Sun, 29 May 2016 22:45:22 +0200 Received: from 145.132.48.198 ([145.132.48.198]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 May 2016 22:45:21 +0200 Received: from ftoth by 145.132.48.198 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 May 2016 22:45:21 +0200 To: linux-btrfs@vger.kernel.org From: Ferry Toth Subject: Re: Hot data tracking / hybrid storage Date: Sun, 29 May 2016 20:45:16 +0000 (UTC) Message-ID: References: <20160516010524.7e208f96@jupiter.sol.kaishome.de> <0d68f988-e117-4b61-cb9b-d18a26e2b909@gmail.com> <20160517203335.5ff99a05@jupiter.sol.kaishome.de> <20160519200926.0a2b5dcf@jupiter.sol.kaishome.de> <1c1358af-4549-618a-c408-b93832d33225@gmail.com> <9bde1aa8-fac5-34c4-dffc-0bf15d86c008@gmail.com> <574A8AFF.7020606@gmail.com> <574B2EE6.6080402@applied-asynchrony.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-btrfs-owner@vger.kernel.org List-ID: Op Sun, 29 May 2016 12:33:06 -0600, schreef Chris Murphy: > On Sun, May 29, 2016 at 12:03 PM, Holger Hoffstätte > wrote: >> On 05/29/16 19:53, Chris Murphy wrote: >>> But I'm skeptical of bcache using a hidden area historically for the >>> bootloader, to put its device metadata. I didn't realize that was the >>> case. Imagine if LVM were to stuff metadata into the MBR gap, or >>> mdadm. Egads. >> >> On the matter of bcache in general this seems noteworthy: >> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ commit/?id=4d1034eb7c2f5e32d48ddc4dfce0f1a723d28667 >> >> bummer.. > > Well it doesn't mean no one will take it, just that no one has taken it > yet. But the future of SSD caching may only be with LVM. > > -- > Chris Murphy I think all the above posts underline exacly my point: Instead of using a ssd cache (be it bcache or dm-cache) it would be much better to have the btrfs allocator be aware of ssd's in the pool and prioritize allocations to the ssd to maximize performance. This will allow to easily add more ssd's or replace worn out ones, without the mentioned headaches. After all adding/replacing drives to a pool is one of btrfs's biggest advantages.