3 ms·
NFS is a lot faster. A custom protocol will almost always beat a kludge on top of HTTP
by api 6y ago
NFS is a lot faster. A custom protocol will almost always beat a kludge on top of HTTP
- fulafel 6y agoBut NFS isn't a custom protocol for any specific app either, and apps that need good fs performance (eg databases, video editing platforms, "big data" compute platforms etc) avoid it. Implementation-wise HTTP has the advantage that the apps can tune the client code because the protocol client implementation isn't in the kernel. In addition HTTP security (transport & user authentication) is works and everyone understands it, whereas on NFS it's a huge mess and enemy of interoperability. In practical popularity NFS fares extremely poorly eg on AWS (how many apps use EFS vs S3).
- ralph84 6y agoEFS is much more expensive than S3, so there is a strong incentive to make your app work with S3 unless you absolutely need a filesystem.
- kondro 6y agoAs with all things AWS, it depends. Yes EFS is 30¢ per GB and S3 is 2.3¢. But S3 also charges $5/million object writes (and 40¢ for reads), but EFS is "free" (factoring burst capacity, per-instance maximum throughput limits, etc). Couple that with EFS' lifecycle migration allowing you to get storage costs as low as 2.5¢/GB for many write-once-read-(almost)never after 7 day applications, things get a lot more complicated.
- anderspitman 6y agoYeah, that's what I was alluding to by saying it would likely not be ideal from a technical perspective. But raw TCP with a custom protocol is faster also, and yet many (most? all?) mobile apps use HTTP+JSON, even if they don't have a web app to support.
- peterwwillis 6y agoMost internet applications use HTTP because real networking is a pain, designing a custom protocol correctly is difficult, and HTTP provides enough functionality and flexibility to munge network traffic any way you want. They use JSON because it's the least pain in the ass of all the data formats. Custom protocol over UDP is the fastest, which NFS supports, so NFS is basically the fastest (unless you get into wonky multiplex-streamed custom apps). However, UDP apps do not often work well through firewalls.
- skissane 6y agoI'm wondering if we are going to see NFS-over-QUIC. Widespread adoption of QUIC may make more firewalls become UDP-friendly.
- ComputerGuru 6y agoNFS is a really slow churning wheel. I think you’ll probably first see an inefficient generic option to tunnel tcp over quic (on both ends) that someone will hack to support nfs before you see an NFSv5 with quic support.
- fulafel 6y agoNFS is not particularly married to UDP though, unless we're talking about old timey NFSv2. There was even a WebNFS spec back in the day designed to let Java applets mount stuff over the internet.
- anderspitman 6y agoI feel like I'm fairly familiar with the tradeoffs. I'm simply making an observation that it's interesting to me that filesystem access over HTTP isn't bigger than it is.
- dnautics 6y ago> filesystem access over HTTP isn't bigger than it is. I don't think it's a trade-off thing. It's conceptual; FS over HTTP is not bigger than it is because filesystems are a much more stateful concept that often has to support coordinative transactions (like locks) whereas HTTP is a stateless protocol by design, so there's fundamentally a mismatch. That's why HTTP is better matched for an object system like S3 which is capable of being transported over stateless links and gives fewer coordination guarantees and is only eventually consistent.