6 ms·

FlashCache at Facebook from 2010 to 2013 and beyond

44 points by wakaflockafliz 13y ago

wakaflockafliz 13y ago
For reference, the FlashCache project and source code is publicly available on github: https://github.com/facebook/flashcache/ https://github.com/facebook/flashcache/
biobot 13y ago
Too bad it is GPL v2. https://github.com/facebook/flashcache/blob/master/LICENSE https://github.com/facebook/flashcache/blob/master/LICENSE
- HarrisonFisk 13y ago
  Why would the license matter for a kernel module? You know that the linux kernel is also GPL v2 right?
  - erichocean 13y ago
    How about the usual reason? Because it can't be pulled into non-GPL projects. This is actually relevant, at least, to me. I've been porting Twitter's fatcache[1] to iOS, and wouldn't be if it was GPL'd. I haven't even looked at Facebook's code, due to the GPL license, which makes it—literally—unusable to me on iOS and Android. [1] https://github.com/twitter/fatcache https://github.com/twitter/fatcache
    - hdevalence 13y ago
      It's indeed terribly unfortunate that you can't take free software and make it nonfree.
    - SEJeff 13y ago
      But it is kernel code. Would you expect it to be trivial to port a device mapper kernel module from Linux to Darwin? Seems like a bit of a stretch
    - btilly 13y ago
      It is possible to make a legal argument that a Linux-specific device driver is in fact derivative of the Linux kernel code that it interacts with. If said argument is made, then no matter what the author of said code says, it may actually be forced to be GPL v2. I am not a lawyer, and I have no real idea how likely said argument is to hold up in an actual court. It also seems unlikely that anyone would actually file a lawsuit about this sort of stuff. But if you want to be as careful as you can be, you won't go wrong if you use the GPL v2 on principle for a Linux device driver. On this topic it is worth noting that Linus Torvalds has stated different seeming opinions at different times. In general as more and more of the Linux kernel has been made available to loadable modules, he's become less and less inclined towards the argument that they are not derivative works. See http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.... for a comparison of his views at two points in time. (I don't know his current views.)
      - kristopher 13y ago
        As the copyright holder of a specific work, you can license the said work any way you like (GPLv2, Commercial, BSD, Apache, et cetera). Dual licensing [1] is not out of the question. [1] http://en.wikipedia.org/wiki/Multi-licensing http://en.wikipedia.org/wiki/Multi-licensing
      - ithkuil 13y ago
        IANAL, but if you create a derivative work of GPL v2 code you have to release it as GPL v2. This doesn't mean you, the copyright holder, cannot release it also with another license. The GPL forces you to ensure that people can use your extension of the original code with the same rules of the original code. In case of kernel modules, if you distribute a binary built with kernel headers (like distributions do, then the sources of that kernel module have to be available under the the GPL license. But if you distribute the sources of a kernel module, and each user compiles it, you can legally load it into a kernel without breaking the GPL. That's how ZFS can legally run on linux as a native module. I don't know if that's really necessary, but better safe than sorry. Distributions can automate this compilation step so that from the point of view of the end user it doesn't make any difference, just a nuisance to the package maintainers (and yes, a few more mb of downloads for compilers and such).
- deleted 13y ago
  [deleted]
McGlockenshire 13y ago
How does flashcache compare to dm-cache / bcache, integrated into linux kernels 3.9 and 3.10? The text mentions that it works as a device mapper module, so does it actually work with dm-cache? The readme on github suggests that it targets older kernel versions, most of which look like versions that ship in RHEL & Ubuntu LTS.
- viraptor 13y ago
  The best thing is that you don't have to prepare the original partitions in any specific way, like with bcache. You just add new partion and say - this is a cache for volume /dev/.... and it works. I don't know about performance differences - haven't used bcache that much. The versions in readme are slightly out of date. Maybe that's what facebook uses internally, but the driver seems to work perfectly with higher versions. I submitted some patches to update function signatures in 3.9, but that was only to get rid of compilation warnings - everything else still works.
- nwmcsween 13y ago
  bcache should be faster, it's at a lower level, That said there are differences mainly the block size and distribution algorithm but could be easily 'fixed' given patches and benchmarks.

For reference, the FlashCache project and source code is publicly available on github: https://github.com/facebook/flashcache/ https://github.com/facebook/flashcache/

biobot 13y ago

Too bad it is GPL v2. https://github.com/facebook/flashcache/blob/master/LICENSE https://github.com/facebook/flashcache/blob/master/LICENSE

HarrisonFisk 13y ago
Why would the license matter for a kernel module? You know that the linux kernel is also GPL v2 right?
- erichocean 13y ago
  How about the usual reason? Because it can't be pulled into non-GPL projects. This is actually relevant, at least, to me. I've been porting Twitter's fatcache[1] to iOS, and wouldn't be if it was GPL'd. I haven't even looked at Facebook's code, due to the GPL license, which makes it—literally—unusable to me on iOS and Android. [1] https://github.com/twitter/fatcache https://github.com/twitter/fatcache
  - hdevalence 13y ago
    It's indeed terribly unfortunate that you can't take free software and make it nonfree.
  - SEJeff 13y ago
    But it is kernel code. Would you expect it to be trivial to port a device mapper kernel module from Linux to Darwin? Seems like a bit of a stretch
  - btilly 13y ago
    It is possible to make a legal argument that a Linux-specific device driver is in fact derivative of the Linux kernel code that it interacts with. If said argument is made, then no matter what the author of said code says, it may actually be forced to be GPL v2. I am not a lawyer, and I have no real idea how likely said argument is to hold up in an actual court. It also seems unlikely that anyone would actually file a lawsuit about this sort of stuff. But if you want to be as careful as you can be, you won't go wrong if you use the GPL v2 on principle for a Linux device driver. On this topic it is worth noting that Linus Torvalds has stated different seeming opinions at different times. In general as more and more of the Linux kernel has been made available to loadable modules, he's become less and less inclined towards the argument that they are not derivative works. See http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.... for a comparison of his views at two points in time. (I don't know his current views.)
    - kristopher 13y ago
      As the copyright holder of a specific work, you can license the said work any way you like (GPLv2, Commercial, BSD, Apache, et cetera). Dual licensing [1] is not out of the question. [1] http://en.wikipedia.org/wiki/Multi-licensing http://en.wikipedia.org/wiki/Multi-licensing
    - ithkuil 13y ago
      IANAL, but if you create a derivative work of GPL v2 code you have to release it as GPL v2. This doesn't mean you, the copyright holder, cannot release it also with another license. The GPL forces you to ensure that people can use your extension of the original code with the same rules of the original code. In case of kernel modules, if you distribute a binary built with kernel headers (like distributions do, then the sources of that kernel module have to be available under the the GPL license. But if you distribute the sources of a kernel module, and each user compiles it, you can legally load it into a kernel without breaking the GPL. That's how ZFS can legally run on linux as a native module. I don't know if that's really necessary, but better safe than sorry. Distributions can automate this compilation step so that from the point of view of the end user it doesn't make any difference, just a nuisance to the package maintainers (and yes, a few more mb of downloads for compilers and such).
deleted 13y ago
[deleted]

McGlockenshire 13y ago

How does flashcache compare to dm-cache / bcache, integrated into linux kernels 3.9 and 3.10? The text mentions that it works as a device mapper module, so does it actually work with dm-cache? The readme on github suggests that it targets older kernel versions, most of which look like versions that ship in RHEL & Ubuntu LTS.

viraptor 13y ago
The best thing is that you don't have to prepare the original partitions in any specific way, like with bcache. You just add new partion and say - this is a cache for volume /dev/.... and it works. I don't know about performance differences - haven't used bcache that much. The versions in readme are slightly out of date. Maybe that's what facebook uses internally, but the driver seems to work perfectly with higher versions. I submitted some patches to update function signatures in 3.9, but that was only to get rid of compilation warnings - everything else still works.
nwmcsween 13y ago
bcache should be faster, it's at a lower level, That said there are differences mainly the block size and distribution algorithm but could be easily 'fixed' given patches and benchmarks.