[lkml]   [2004]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: NFS client behavior on close
    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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:03    [W:0.019 / U:0.700 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site