Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've just skimmed the TOC and, having never seen this book before, I'm a little in love. Here's why

It's a cynical UNIX manual from the 1990's. Here:

> 14 NFS..............283

> Nightmare File System

> Not Fully Serviceable............284

> No File Security...........287

> Not File System Specific? (Not Quite)..........292

Here also:

> The Oxymoronic World of Unix Security .......243

> Holes in the Armor ........244

> The Worms Crawl In ..........257

I work in IT systems development in a University IT department. I want to read this take on UNIX from 1994, just to see how much better things haven't gotten.

OK, the state of the art has gotten better, but if I compare my work environment which is byzantine complexity and full of bespoke garbage sometimes, to the hells apparently described herein, I bet I can find more similarities than differences.

And that will hopefully make me a more effective communicator about how to make things better with modern convenience technologies that we're not using enough. (Dare I say Kubernetes is the one big thing that is actually majorly different today, compared to UNIX in the 1990's.)



> I bet I can find more similarities than differences.

Most of what's on the book has been fixed (not NFS, this one is forever), and we have an entirely new set of things to worry about.

The book is funny, but every part of it feels old.


Rereading the section on NFS again, I suddenly realize that I was foolish to have skipped it as out of date. Since my last read I have encountered some incarnation (heh) of every single one of the problems listed in that chapter. I'm betting v4 isn't much better either. Is there a good network file system solution!?


What's wrong with nfs v4? It was quite a bit faster than the alternatives last I checked.


As the book says:

> There’s only one problem with a connectionless, stateless (file) system: it doesn’t work.

> Example #1: NFS is stateless, but many programs designed for Unix systems require record locking

> Example #3: If you delete a file in Unix that is still open, the file’s name is removed from its directory, but the disk blocks associated with the file are not deleted until the file is closed.

(Example #2 is a non-issue)

The security is still lacking, and the system still can't handle failures.

Yet, yes, it's faster, easier to set-up, and more widely supported than the alternatives.


One of the saddest to see edits to Wikipedia is this one to its article on NFS.

* https://en.wikipedia.org/w/index.php?diff=385927363&oldid=38...

There has been a lot of literature published on the problems with NFS, and the mismatch with POSIX file semantics, since 1988. Some of it was even in the original paper from Sun, in fact. To this day, Wikipedia has nothing on the subject. The words "stateful" and "stateless" appear once each in the entire article, with no indication of their pivotal importance, made much of in the actual literature on the subject.

* https://news.ycombinator.com/item?id=17950343


Lustre.


Any thoughts re: the comments here [0] about usability for smaller workloads?

0. https://news.ycombinator.com/item?id=14165785




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: