Hacker News Reader

Comment by ealexhudson | Hacker News Reader

I think this is a great product, but I've been actively avoiding NFS for a while now. It's a real shame that there isn't a better network FS protocol standardized already - NFS is complex, is usually a single point of failure (would be interesting to know if EFS isn't...) and comes with a whole set of cruft.

View on HN

I understand why they did it, though. It's either this (everyone supports NFS, even Windows) or get crucified for vendor lock-in. Just like Github did yesterday (https://news.ycombinator.com/item?id=9343021), even when they released their product as an open standard with an open source reference implementation.

Well, indeed, I'm not sure I could offer a different choice I would have preferred - so the criticism definitely isn't constructive in that sense. It does seem, though, that the world is missing a sane cross-platform network system. If there had even been some fuse-based system that used a more robust protocol I'd probably prefer that, although if they can more or less guarantee that the NFS service won't go down (easily) then I suppose most of my qualms would be put aside.

There's a world of difference between what Github did, and the hypothetical where AWS chose a proprietary protocol to access a filesystem. For AWS, as long as the underlying filesystem was "more or less POSIX", the access mechanism is largely irrelevant to lock-in; it would be as easy to switch from AWS as it would be to move between filesystems.

Git was not designed for large files. But what github released yesterday primarily serves to promote github's central-server model for git. Moreover, it seems that it could have been better done within the git protocol itself (modify git to do more sparse pulls, and then try to fetch on a checkout when it is missing blobs, rather than erroring immediately).

I suspect AWS chose to use NFS for expedience, the net effect is positive, but I don't think it would have much mattered anyway.

Github is trying to inject their own server-model into the git protocol, with an extension that is only half thought through; that is a huge step backwards, open-source or not.

NFS is definitely wonky if you are using cheap tools, but high end systems give astonishing performance.

9p is a better network filesystem protocol, and it's available on Linux.

That's enticing, are there any references/benchmarks to back it up?

The protocol itself is much cleaner, but I'm not aware of any recent benchmarks.

Compare https://ericvh.github.io/9p-rfc/rfc9p2000.html vs https://tools.ietf.org/html/rfc5661

TODO: conduct this comparison when 9p specification is not full of "TODOs"...

Oops, missed that. This is more complete: http://man.cat-v.org/plan_9/5/intro

From my own benchmark, on kernel Linux 3.19.3.201503270049-1-grsec, qemu 2.2.1, 9p was 500% slower on read and immensily - after 9min gave on the write test which took 29s on host.

What's your experience been running it in production? Any gotchas?

We use it to share filesystems into QEMU/KVM VMs, so far zero issues, but it's not a performance-constrained use case.

I do have some plans to do benchmarks for another use case that's more performance intensive, but it's buried in my backlog right now.

Can you do a simple time sh -c "dd if=/dev/zero of=testfile bs=8k count=11000"; rm testfile

"performance" test?

Also do the read test on a really big file, first from your host - so the file will get cached, then from within the qemu-vm where virtfs plan9 is mounted, dd if=bigfile of=/dev/null

Please, I want to confirm its not only my machines suffering from really totally shitty read/write performance thru virtfs?

Its performance for me was 500% slower than NFS which was only 30% slower than direct IO.

No time to investigate.

Reply on news.ycombinator.com