|
|
|
|
|
|
by chubot
5533 days ago
|
|
|
The point of the article is that you are taking an ancient interface and using it for something new. Millions of lines of code was written against that interface with old assumptions, and now you've moved it to a new implementation without changing any of it. Things are bound to go wrong. When you move sqlite to NFS, for example, file locking probably won't work. There is nothing to tell you this. It sounds like you have experience making NFS work well, but I don't see how anything you wrote addresses this point. In fact I think you're just echoing some of the article's points about "enterprise planning". AFAICT you come from the enterprise world and are advocating overprovisioning, which is fine, but not the same context. |
|
|
It's not that I believe in overprovisioning I think. It's that if data is really that critical, and it's availability is critical, then that has to be taken into account during planning.
Everything fails at some point. The Enterprise Storage Vendors would have you believe their stuff doesn't. In practice it's pretty scary when the black box doesn't work as advertised anymore though _after_ you've made it the centerpiece of your operations.
So with those lessons learned, our replacement efforts took into account the level of availability we wanted to achieve.
I did go off on an NFS tanget. Sorry. But this article was about block-storage, which is a different beast from what you describe.
Seeing all networked storage lumped together is like seeing: FastCGI isn't 100% reliable, which is why I hate two-phase-commits.