Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 20 Nov 2017 20:53:03 +0000 (UTC)
From:      Scott Long <scottl@FreeBSD.org>
To:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   svn commit: r326029 - head/sys/kern
Message-ID:  <201711202053.vAKKr3Gk063462@repo.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: scottl
Date: Mon Nov 20 20:53:03 2017
New Revision: 326029
URL: https://svnweb.freebsd.org/changeset/base/326029

Log:
  Update a comment in brelse() to match reality.

Modified:
  head/sys/kern/vfs_bio.c

Modified: head/sys/kern/vfs_bio.c
==============================================================================
--- head/sys/kern/vfs_bio.c	Mon Nov 20 20:05:30 2017	(r326028)
+++ head/sys/kern/vfs_bio.c	Mon Nov 20 20:53:03 2017	(r326029)
@@ -2340,9 +2340,18 @@ brelse(struct buf *bp)
 	    !(bp->b_flags & B_INVAL)) {
 		/*
 		 * Failed write, redirty.  All errors except ENXIO (which
-		 * means the device is gone) are expected to be potentially
-		 * transient - underlying media might work if tried again
-		 * after EIO, and memory might be available after an ENOMEM.
+		 * means the device is gone) are treated as being
+		 * transient.
+		 *
+		 * XXX Treating EIO as transient is not correct; the
+		 * contract with the local storage device drivers is that
+		 * they will only return EIO once the I/O is no longer
+		 * retriable.  Network I/O also respects this through the
+		 * guarantees of TCP and/or the internal retries of NFS.
+		 * ENOMEM might be transient, but we also have no way of
+		 * knowing when its ok to retry/reschedule.  In general,
+		 * this entire case should be made obsolete through better
+		 * error handling/recovery and resource scheduling.
 		 *
 		 * Do this also for buffers that failed with ENXIO, but have
 		 * non-empty dependencies - the soft updates code might need



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201711202053.vAKKr3Gk063462>