Bcache For The Linux Kernel Might Finally Be Ready

[phoronix]

Phoronix: Bcache For The Linux Kernel Might Finally Be Ready

It's been a long time coming, but Bcache might finally be merged soon into the mainline Linux kernel. Bcache provides a block-layer SSD cache for Linux with write-back and write-through support for solid-state drives...

http://www.phoronix.com/vr.php?view=MTI3NDg

[marklaar]

"Write-back and write-through caching models are supported by Bcache while also working at the block level so it supports any file-system, unlike L2Arc with the ZFS file-system."

...really? I thought ZFS caching worked at block-level, so it wouldn't matter if you were using a zvol or ZFS's own filesystem? Particularly interested in the details of this from a FreeBSD perspective.

Thanks.

[pdffs]

"Write-back and write-through caching models are supported by Bcache while also working at the block level so it supports any file-system, unlike L2Arc with the ZFS file-system."

...really? I thought ZFS caching worked at block-level, so it wouldn't matter if you were using a zvol or ZFS's own filesystem? Particularly interested in the details of this from a FreeBSD perspective.

Yes, but it only works when backed by a zpool. When people say ZFS, they're talking about the whole ZFS stack - you can't separate the components, ZFS is both a volume manager and a filesystem.

Perhaps that quote could have been more precise:

"Write-back and write-through caching models are supported by Bcache while also working at the block level so it supports any block device (and hence filesystem), unlike L2Arc from ZFS."

[BO$$]

If they keep on adding stuff in the kernel it will end up having 50 millions of code. And will be unmaintainable. I'm not saying they shouldn't add this feature but still....

[Linuxhippy]

If they keep on adding stuff in the kernel it will end up having 50 millions of code. And will be unmaintainable. I'm not saying they shouldn't add this feature but still....

Well, you have actually two choices here. Either you keep your kernel-interface stable for a long time (the may how Microsoft does it), or you distribute everything in a gigantic tarball and keep it self-contained. Both approaches have pros and cons - however, at least I think for the kernel the second model worked pretty well for the last ... 20 years. I don't see a reason why suddenly it shouldn't work anymore.

By the way, BCache is actually really great. Once its in, I think I can't resist actually buying a mSATA SSD as well as a 1TB HDD for my 12' notebook.

Regards

[liam]

Well, you have actually two choices here. Either you keep your kernel-interface stable for a long time (the may how Microsoft does it), or you distribute everything in a gigantic tarball and keep it self-contained. Both approaches have pros and cons - however, at least I think for the kernel the second model worked pretty well for the last ... 20 years. I don't see a reason why suddenly it shouldn't work anymore.

By the way, BCache is actually really great. Once its in, I think I can't resist actually buying a mSATA SSD as well as a 1TB HDD for my 12' notebook.

Regards

Well, depending on what you mean by kernel interface, the linux kernel can be seen as having a well maintained backwards compatibility. It's access to their ABI that is the problem, but unless you're looking at kernel modules, this isn't a big issue.

BTW, I really hope this gets merged. Bcache seems the proper way to handle this sort of mechanism.

[pdffs]

Anyone have an opinion at this stage on Bcache vs EnhanceIO?

[ryao]

"Write-back and write-through caching models are supported by Bcache while also working at the block level so it supports any file-system, unlike L2Arc with the ZFS file-system."

...really? I thought ZFS caching worked at block-level, so it wouldn't matter if you were using a zvol or ZFS's own filesystem? Particularly interested in the details of this from a FreeBSD perspective.

Thanks.

You are correct. ZFS' caching is not limited to itself. You need still to put other things on zvols for them to benefit, but the same action is needed for alternatives.