5 ms·

The website doesn't seem to mention that several of the papers on the filesystem won best-paper awards at major conferences. The paper, Optimizing Every Operati

The website doesn't seem to mention that several of the papers on the filesystem won best-paper awards at major conferences. The paper, Optimizing Every Operation in a Write-Optimized File System, in particular, won best-paper award at FAST '16. Also, if you're interested in learning more about B^\epsilon trees, here's a talk given by Rob Johnson a few years ago at Microsoft Research: BetrFS: A Right-Optimized Write-Optimized File System https://www.youtube.com/watch?v=fBt5NuNsoII https://www.youtube.com/watch?v=fBt5NuNsoII In general, I think it's really cool that there is a file system that exists today (i.e., BetrFS) that uses data structures which didn't exist 25 years ago. It's a great example of theoreticians and systems researchers working together.

swills 5y ago
The reason I posted it was I saw it in the FAST21 playlist: https://www.youtube.com/watch?v=6KueHK9i8lE https://www.youtube.com/watch?v=6KueHK9i8lE
pengaru 5y ago
> here's a talk given by Rob Johnson a few years ago at Microsoft Research: BetrFS: A Right-Optimized Write-Optimized File System https://www.youtube.com/watch?v=fBt5NuNsoII https://www.youtube.com/watch?v=fBt5NuNsoII Interesting talk, I wonder how much of the perf. advantage diminishes in a finished, production-ready implementation though. Comparing an 80%-complete R&D prototype mule against crash-resilient posix-compliant production filesystems is basically never a fair perf. comparison. You might find that just implementing rename and hard-links properly alone is going to kill your perf. since you dispensed with on-disk inode equivalents. Nice to see people poking at these issues nonetheless, Linux needs better filesystem options.
- zokier 5y ago
  On the other hand I can easily imagine lot of applications that don't care about full posix compliance, and are perfectly happy to trade handling of some obscure feature for improved performance.
  - c0balt 5y ago
    Maybe a viable option for single-application container images. They would on the one side offer the ability to have tight control around used functions (to allow for missing features) but also be able to exactly target an FS and be optimized for it.
    - fartattack 5y ago
      Containers don't control the FS that they're written to. A container image is in the tar format and at runtime the underlying FS is defined by the host, which is why containers only run on hosts with union filesystems
  - pengaru 5y ago
    Renames and hard-links are not obscure features. And there are myriad mount options for tailoring performance vs. crash-resilience/posix-compliance to the application in most the existing production filesystems. Which was honestly another aspect of the talk that was somewhat lacking; what journaling modes were used? barrier/nobarrier? was it even made equivalent to what betrfs achieves? We don't even know if a betrfs instance can successfully mount after a mid-write hard reboot.

swills 5y ago

The reason I posted it was I saw it in the FAST21 playlist: https://www.youtube.com/watch?v=6KueHK9i8lE https://www.youtube.com/watch?v=6KueHK9i8lE

pengaru 5y ago

> here's a talk given by Rob Johnson a few years ago at Microsoft Research: BetrFS: A Right-Optimized Write-Optimized File System https://www.youtube.com/watch?v=fBt5NuNsoII https://www.youtube.com/watch?v=fBt5NuNsoII Interesting talk, I wonder how much of the perf. advantage diminishes in a finished, production-ready implementation though. Comparing an 80%-complete R&D prototype mule against crash-resilient posix-compliant production filesystems is basically never a fair perf. comparison. You might find that just implementing rename and hard-links properly alone is going to kill your perf. since you dispensed with on-disk inode equivalents. Nice to see people poking at these issues nonetheless, Linux needs better filesystem options.

zokier 5y ago
On the other hand I can easily imagine lot of applications that don't care about full posix compliance, and are perfectly happy to trade handling of some obscure feature for improved performance.
- c0balt 5y ago
  Maybe a viable option for single-application container images. They would on the one side offer the ability to have tight control around used functions (to allow for missing features) but also be able to exactly target an FS and be optimized for it.
  - fartattack 5y ago
    Containers don't control the FS that they're written to. A container image is in the tar format and at runtime the underlying FS is defined by the host, which is why containers only run on hosts with union filesystems
- pengaru 5y ago
  Renames and hard-links are not obscure features. And there are myriad mount options for tailoring performance vs. crash-resilience/posix-compliance to the application in most the existing production filesystems. Which was honestly another aspect of the talk that was somewhat lacking; what journaling modes were used? barrier/nobarrier? was it even made equivalent to what betrfs achieves? We don't even know if a betrfs instance can successfully mount after a mid-write hard reboot.