From owner-freebsd-hackers Sun Jun 27 19:19: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from Twig.Rodents.Montreal.QC.CA (Twig.Rodents.Montreal.QC.CA [132.206.78.3]) by hub.freebsd.org (Postfix) with ESMTP id ABD3314E30 for ; Sun, 27 Jun 1999 19:19:00 -0700 (PDT) (envelope-from mouse@Twig.Rodents.Montreal.QC.CA) Received: (from mouse@localhost) by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id WAA00668; Sun, 27 Jun 1999 22:18:22 -0400 (EDT) Date: Sun, 27 Jun 1999 22:18:22 -0400 (EDT) From: der Mouse Message-Id: <199906280218.WAA00668@Twig.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: Francois-Rene Rideau , FreeBSD Hackers , NetBSD Kernel , OpenBSD Kernel , Linux Kernel Subject: Re: Improving the Unix API Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> -f The filesystem is forcibly unmounted. Active special devices >> continue to work, but all other files return errors if further >> accesses are attempted. > I think that returning errors is WRONG, unless [...] > It means that you can't fix the problem with the filesystem and > resume operations nicely afterwards; I think I see part of the problem here. You are thinking "unmount to fix problem, will remount later". "umount -f" is more like "it's going away, dammit, and I'd rather crash a few processes than have to take down the whole system". It might be worthwhile having an option that causes attempted accesses to hang until the filesystem comes back online, somewhat akin to Auspex's filesystem "isolation". der Mouse mouse@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message