From owner-freebsd-current Mon Nov 6 10:17:39 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA05801 for current-outgoing; Mon, 6 Nov 1995 10:17:39 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA05795 for ; Mon, 6 Nov 1995 10:17:32 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA15483; Mon, 6 Nov 1995 11:13:26 -0700 From: Terry Lambert Message-Id: <199511061813.LAA15483@phaeton.artisoft.com> Subject: Re: Info on my Sunday commits To: dyson@freefall.freebsd.org (John Dyson) Date: Mon, 6 Nov 1995 11:13:26 -0700 (MST) Cc: current@FreeBSD.org In-Reply-To: <199511060035.QAA24457@freefall.freebsd.org> from "John Dyson" at Nov 5, 95 04:35:32 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1170 Sender: owner-current@FreeBSD.org Precedence: bulk > MNT_ASYNC now means even more on UFS. More of the meta-data is written > asynchronously and the VREG data is now written asynchronously. I think > that even more can be done relatively safely. This can really help on > bulk file restores or perhaps news spool partitions. UFS has a number of places it gratuitously uses sync I/O to fix code errors. One of the engineers here at Artisoft has rolled some changes that result in some significant speed increases with no reduction in reliability and no change to the on disk layout. The changes are pointed out in the Herrin/Finkel VIVAFS work as changes they made to make VIVA faster, but it seems that all but two of the major changes are directly applicable to UFS as well. Check Technical Report Number 225-93 at the University of Kentucky CS Department (ms.uky.edu?). I haven't looked at the MNT_ASYNC changes yet, but based on its previous behaviour, I strongly caution against using MNT_ASYNC except in very special circumstances, like volume copying or backup, etc.. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.