Yes, also it does not have data corruption issues reported with overlays (readers vs writers). Also it supports atomic rename. NO whiteouts required as in the case of a union file systems (so not to worry about deleted files coming back).
Yes, it is a native file system optimized for large number of containers (clones), sharing read only image layers. LCFS also understands the ephemeral nature of data stored in /var/lib/docker and avoids some of the complexities seen in general purpose file systems.
I'm very suspicious of their benchmarks - all of the tests they list are largely network-bound (including build, as the Dockerfile they are presumably using to do the build is mostly apt-get/wget instructions), and there's zero discussion of how they eliminated network variance. Using docker pull/wget/etc to benchmark a filesystem gives me very little faith that they really understand what they're doing.
Furthermore the install script is troubling: "sudo curl ... | bash" -- in this curl runs as root, but bash runs as the user, which is definitely not what you want to do. Either they should both run as the user, or curl should run as the user and bash as root. But not this.
The setup script also looks like it wants to nuke /var/lib/docker, which may be an unpleasant surprise to people wanting to try this.
Honestly, the more I look at this, the more I can't help but shake the feeling that this really isn't everything it claims to be.
The tests were run against a local repository to remove network variability.
Your comment on using docker pull to benchmark a file system perplexes me. This is not a general purpose file system, it is purpose built for only one use case - the graph driver.
The good news is that this is all open source, so if there is a specific concern, this should be opened as an issue on the github. The claims are also easy to validate (or refute)... since you can just run it on your own system. Please do share that experience on github, as we are genuinely interested in making this successful for everyone.
The install setup experience is definitely something worth pointing out. This is an area where it is not as smooth as it should be, but we are working with Docker to work on those issues. We need a richer set of interfaces to make the v2 plugin interface work... note that the v2 plugin interface is still in beta. This is in no was a finished project, we are working with others in the community to see this through.
The README is updated with more details on the tests performed. Also concerns raised about setup scripts are fixed now. Thanks a lot for pointing those out.
I am not surprised on your first impression that the published results are too good to be true. But we have proved that a custom built solution can outperform half baked solutions very easily, in addition to providing correctness.
7 comments
[ 0.18 ms ] story [ 36.6 ms ] threadThis quote from the Readme stands out:
> The LCFS filesystem operates directly on top of block devices, as opposed to over two filesystems that are then merged.
Furthermore the install script is troubling: "sudo curl ... | bash" -- in this curl runs as root, but bash runs as the user, which is definitely not what you want to do. Either they should both run as the user, or curl should run as the user and bash as root. But not this.
The setup script also looks like it wants to nuke /var/lib/docker, which may be an unpleasant surprise to people wanting to try this.
Honestly, the more I look at this, the more I can't help but shake the feeling that this really isn't everything it claims to be.
Your comment on using docker pull to benchmark a file system perplexes me. This is not a general purpose file system, it is purpose built for only one use case - the graph driver.
The good news is that this is all open source, so if there is a specific concern, this should be opened as an issue on the github. The claims are also easy to validate (or refute)... since you can just run it on your own system. Please do share that experience on github, as we are genuinely interested in making this successful for everyone.
The install setup experience is definitely something worth pointing out. This is an area where it is not as smooth as it should be, but we are working with Docker to work on those issues. We need a richer set of interfaces to make the v2 plugin interface work... note that the v2 plugin interface is still in beta. This is in no was a finished project, we are working with others in the community to see this through.
I am not surprised on your first impression that the published results are too good to be true. But we have proved that a custom built solution can outperform half baked solutions very easily, in addition to providing correctness.