Date: Fri, 11 May 2001 10:40:14 -0700 From: Kirk McKusick <mckusick@mckusick.com> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/ufs/ffs fs.h softdep.h ffs_softdep.c ... Message-ID: <200105111740.KAA15819@beastie.mckusick.com> In-Reply-To: Your message of "Fri, 11 May 2001 10:36:07 EDT." <200105111436.KAA93071@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Date: Fri, 11 May 2001 10:36:07 -0400 (EDT) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: Kirk McKusick <mckusick@mckusick.com> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/ufs/ffs fs.h softdep.h ffs_softdep.c .. In-Reply-To: <200105110227.TAA14458@beastie.mckusick.com> <<On Thu, 10 May 2001 19:27:42 -0700, Kirk McKusick <mckusick@mckusick.com> said: > At the point that you know that there are no blocks currently > available, you are deep in the allocation code holding a > vnode locked. For cases where a system call was interrupted by a signal and needs to be restarted, an ``unwind and retry'' error (ERESTART) was invented for internel kernel use. It seems to me that the same sort of approach (ECANTBLOCKNOW?) ought to work for this case as well. -GAWollman An intriguing idea. It would be a rather inefficient solution, but could be made to work. I would still want to have some proactive flushing going on so that processes would not be delayed up to the usual 60 seconds to get their space. Kirk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105111740.KAA15819>