191–200 of 217 posts
Earlier quoted context omitted.
9p is a better network filesystem protocol, and it's available on Linux.
What's your experience been running it in production? Any gotchas?
No time to investigate.
Earlier quoted context omitted.
May I ask why? My experience with NFS is pretty bad performance wise.
Not sure why NFS gets such a bad rap. On a low-latency network, properly tuned NFS has very few, if any performance issues. I've personally seen read/write rates exceeding 800MByte/sec on more or less white-box hardware, at which point it was limited by the underlying storage infrastructure (8Gbit fiber), not the NFS protocols. Dell has a 2013 white paper (I'm not affiliated with them, fwiw) about their fairly white…
Not sure how it would ever be technically possible for a networked filesystem to get even near directly attached storage. But, for sure, the typical carrier grade EMC or Netapp is MUCH slower then a good SAN. I'm talking about petabytes of very small (average maybe 20kB) files with lots of _random_ sync writes and reads. NFS has a lot of other benefits, but it surely is not super high performance in every usecase. Regardless of what a theoretical marketing whitepaper has shown in some lab setup.
Someone who thinks that you can put a network protocol around a filesystem without _any_ performance impact is nuts.
BUT if your usecase fits NFS you might as well get very good performance out of it. As always, pick the right technology for your specific case.
Earlier quoted context omitted.
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.
"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?
Earlier quoted context omitted.
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?
I wish AWS would be a little more technical in their product descriptions and announcements. If there was ever an audience that wants technical data about how this type of technology will scale and compares to existing technology like glusterfs it would be the AWS users. Instead the performance specifications are ".. and is designed to provide the throughput, IOPS, and low latency needed for a broad range of workload…
As a developer (but not a sysadmin) I feel the opposite. Not saying your criticism is wrong, just giving another view from a AWS newbie perspective. When I read most AWS product descriptions, I cannot understand what real world situations they are for. I either could not say, or could only vaguely say, what the product is in my own words. There seems to be a great scaffolding of assumed knowledge about the AWS system…
Does anyone else cringe when someone suggestions using NFS in production? I can't be the only one that has been woken up at 2am because of an NFS outage.
It works, more than usually but the problem starts whenever it feels like not working. And you can never be sure whenever the tantrum will come.
With linux while using the nfs-kernel-server most of the time you need to restart if a problem occurs. And I don't like restarts.
A few years ago, slabtop helped me to troubleshoot some memory issues, turned out nfs-kernel-server was leaking. I had to upgrade the kernel.
The shame is, there is nothing like nfs to replace nfs. Easy to deploy, easy for clients, works everywhere.
Earlier quoted context omitted.
I think their skill is more profound commercialization. I do in fact remember all of those things. I even owned all of those things before Apple entered those markets. Apple invented very little for any of them. Their strength lies in taking existing technologies, rebuilding them with a strong user focus, and then marketing the hell out of them. So much so that many people apparently forget what came before.
Most of their success is owing to the invention of new interfaces that fit new form factors. Before that, only dissatisfying shit is available, and the market is mostly novelty. After that, new device categories have actual features a human can use, and a market happens and knock offs compete.
Don't get me wrong; those are all very polished products, and they took a lot of technical smarts. They were much more usable to a mainstream consumer audience. But the non-Apple versions of those products were generally fine for non-consumer audiences. And Apple's marketing is masterful; I've never seen a tech company so good at generating hype.
Does anyone else cringe when someone suggestions using NFS in production? I can't be the only one that has been woken up at 2am because of an NFS outage.
XYZ could be NFS, SCSI, MySQL, Rails, KVM, ..., you get the idea. Any technology that has seen wide use has caused someone to be woken up at 2am because of an outage. NFS has been very widely used for a very long time. As a distributed file system developer who once helped design a precursor of pNFS I think NFS has some pretty fundamental problems, but the fact that NFS servers sometimes go down is not one of them. Often that's more to do with the implementation and/or deployment than the protocol, and no functionally similar protocol would do much better under similar circumstances. People get woken up at 2am because of SMB failures too. My brother used to get woken up at 2am because of RFS failures. Nobody gets woken up at 2am because of 9p failures, but if 9p ever grew up enough to be deployed in environments with people on call I'm sure they'd lose sleep too. EBS failures have bitten more than a few people.
Citing the existence of failures, other than proportionally to usage, isn't very convincing. I'd actually be more concerned about the technology on the back end of EFS, not the protocol used on the front.
NFS? I just simply don't see the place for this product. The world moved towards the use of smart data formats on platforms like S3 and HDFS. Where would be a NFS service better? It is kind of hard to see for me to use a distributed filesystem over a distributed datastore. Wondering about the outage scenarios with that. Historically speaking, the drivers that deal with this in the linux kernel are not the best in ter…
(1) Not all development is green-field and thus subject to using this week's fashionable data store. A lot of applications already use file systems and rely on their semantics. Ripping up the entire storage layer of a large and complex application would be irresponsible, as it's likely to create more problems than it solves. Look down your nose at "legacy code" all you want, but those users exist and have money to give people who will help them solve their business problems. Often the solutions are as cutting-edge as anything you'd find in more fashionable quarters, even if the facade is old fashioned.
(2) Even for green-field development, file systems are often a better fit than object stores. Nested directories are more than just an organizational scheme, but also support security in a way that object stores don't. What's the equivalent of SELinux for data stored in S3 or Swift? There is none. File system consistency/durability guarantees can be important, as can single-byte writes to the middle of a file, while parsing HTTP headers on every request drops a lot of functionality and performance on the floor. Distributed databases are much more compelling, but the fact remains that the file system model is often the best one even for new applications.
Go ahead and use something else if it suits you. Other people wouldn't have much use for your favorite storage model, and this one suits them perfectly.