On 2016-05-29 22:45, Ferry Toth wrote:
Op Sun, 29 May 2016 12:33:06 -0600, schreef Chris Murphy:
On Sun, May 29, 2016 at 12:03 PM, Holger Hoffstätte
<hol...@applied-asynchrony.com> 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.
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.
I would certainly vote for this feature. If I understand correctly, the
mirror is selected based on the PID of btrfs worker thread [1], which is
simple but not most effective. I would suggest implementing the queue of
read
operations per physical device (perhaps reads/writes should be put into
same
queue). If device is fast (and for SSD that is the case), the queue
becomes
empty quicker which means it should be loaded more intensively.
Allocation
logic should simply put the next request to the shortest queue. I think
this will guarantee that most operations are served by SSD (or any other
even faster technology that appears in the future).
[1]
https://btrfs.wiki.kernel.org/index.php/Project_ideas#Better_data_balancing_over_multiple_devices_for_raid1.2F10_.28read.29
--
With best regards,
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
