From owner-freebsd-arch Sun Oct 10 19:44:53 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D622F14EB5 for ; Sun, 10 Oct 1999 19:44:51 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA26863 for ; Mon, 11 Oct 1999 04:44:50 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA08421 for freebsd-arch@freebsd.org; Mon, 11 Oct 1999 04:44:49 +0200 (MET DST) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 9123114EB5 for ; Sun, 10 Oct 1999 19:44:42 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40329>; Mon, 11 Oct 1999 12:40:46 +1000 Content-return: prohibited Date: Mon, 11 Oct 1999 12:44:30 +1000 From: Peter Jeremy Subject: Re: The eventual fate of BLOCK devices. In-reply-to: <199910110121.SAA18665@apollo.backplane.com> To: freebsd-arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Oct11.124046est.40329@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <199910110121.SAA18665@apollo.backplane.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Oct-11 11:21:04 +1000, Matthew Dillon wrote: > There are several trivial ways to solve the write-error problem. Unless I've missed something along the way, it's not that simple. Traditionally, a write to a block device sits in the buffer cache until the sync daemon flushes it to disk. I thought that unifying VM and the buffer cache, together with softupdates, would have relatively little impact on this - there's still a write-back cache with the cache flushing occurring asynchronously and independent of the writer. > First, > implement writes as write-through so a synchronous error can be returned. I would have thought that switching from the current write-back to a write-through policy would, in general, entail a significant performance hit. Even if filesystem I/O is excluded (which I believe is the intent), you still lose the I/O clustering benefits. > Second, implement an error code on close. This would seem to be preferable (and even POLA for direct I/O to block devices). The problem I can see is firstly, the delays in syncer and secondly, getting I/O errors from syncer to to process (or processes, since several different processes could have written to the block(s) in question) issuing the close. > There are also situations where > errors can be assumed to not occur, such as when using buffered VN > partition which is backed by a file or swap. The device underlying the filesystem or swap could still suffer errors. At some point, a decision needs to be made that the error is not reported back to the caller, but notified to `the operator' as a `system' error. Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message