Hi- Dai noticed that when a 3.17 Linux NFS client is granted a write delegation, it neglects to flush dirty data synchronously with close(2). The data is flushed asynchronously, and close(2) completes immediately. Normally that’s OK. But Dai observed that: 1. If the server can’t accommodate the dirty data (eg ENOSPC or EIO) the application is not notified, even via close(2) return code. 2. If the server is down, the application does not hang, but it can leave dirty data in the client’s page cache with no indication to applications or administrators. The disposition of that data remains unknown even if a umount is attempted. While the server is down, the umount will hang trying to flush that data without giving an indication of why. 3. If a shutdown is attempted while the server is down and there is a pending flush, the shutdown will hang, even though there are no running applications with open files. 4. The behavior is non-deterministic from the application’s perspective. It occurs only if the server has granted a write delegation for that file; otherwise close(2) behaves like it does for NFSv2/3 or NFSv4 without a delegation present (close(2) waits synchronously for the flush to complete). Should close(2) wait synchronously for a data flush even in the presence of a write delegation? It’s certainly reasonable for umount to try hard to flush pinned data, but that makes shutdown unreliable. Thanks for any thoughts! -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
