I had second thoughts on this.

Reporting background writeout errors via close() only really makes sense if
allthe IO has completed anyway: ie, the app has had the fd open without
writing to it for many tens of seconds.

It would be OK if it was harmless, but it is not.  Changes are, applications
ignore errors from close().  So if an application does a fork/exit and the
child correctly does an fsync() of the fd, the close-on-exit will have wiped
out any accumulated EIO/ENOSPC errors.

Or if someone does dup()/close()/fsync(), the fsync() could fail to detect
earlier errors, thanks to the close.


So.  The clear-and-report of errors on close() makes the reporting of errors
on fsync/msync/fdatasync less reliable.


 fs/open.c |   16 ++++------------
 1 files changed, 4 insertions(+), 12 deletions(-)

diff -puN fs/open.c~no-async-write-errors-on-close fs/open.c
--- 25/fs/open.c~no-async-write-errors-on-close	2003-08-23 14:12:53.000000000 -0700
+++ 25-akpm/fs/open.c	2003-08-23 14:12:53.000000000 -0700
@@ -945,20 +945,12 @@ asmlinkage long sys_creat(const char __u
  */
 int filp_close(struct file *filp, fl_owner_t id)
 {
-	struct address_space *mapping = filp->f_dentry->d_inode->i_mapping;
-	int retval = 0, err;
+	int retval;
 
 	/* Report and clear outstanding errors */
-	err = filp->f_error;
-	if (err) {
+	retval = filp->f_error;
+	if (retval)
 		filp->f_error = 0;
-		retval = err;
-	}
-
-	if (test_and_clear_bit(AS_ENOSPC, &mapping->flags))
-		retval = -ENOSPC;
-	if (test_and_clear_bit(AS_EIO, &mapping->flags))
-		retval = -EIO;
 
 	if (!file_count(filp)) {
 		printk(KERN_ERR "VFS: Close: file count is 0\n");
@@ -966,7 +958,7 @@ int filp_close(struct file *filp, fl_own
 	}
 
 	if (filp->f_op && filp->f_op->flush) {
-		err = filp->f_op->flush(filp);
+		int err = filp->f_op->flush(filp);
 		if (!retval)
 			retval = err;
 	}

_