Messages in this thread | | | Subject | Re: NFS client behavior on close | From | Trond Myklebust <> | Date | Wed, 02 Jun 2004 12:45:21 -0700 |
| |
På on , 02/06/2004 klokka 12:16, skreiv Simon Kirby:
> Ok, that makes sense -- if NFSv2 has no fsync(), then using "async" mode > definitely sounds broken. But is this the same with NFSv3?
The problem is that Linux's "async" implementation short-circuits the NFSv3 fsync() equivalent. Not good!
> NFS should just extend fsync() back to the server -- with minimal caching > on the client, normal write-back caching on the server, and where fsync() > on the client forces the server to write before returning on the client. > Forcing this to happen on close() doesn't even line up with local file > systems.
That still leaves room for races with other clients trying to open the file after the server comes up after a crash, then finding stale data. (Free|Net|Open)BSD choose to ignore that race, and do the above. I'm not aware of anybody else doing so, though...
Performance is good, but it should always take second place to data integrity. There are more than enough people out there who are entrusting research projects, banking data,... to their NFS server.
Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |