From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 09:43:14 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A2D116A401 for ; Tue, 10 Apr 2007 09:43:14 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4906C13C45D for ; Tue, 10 Apr 2007 09:43:14 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HbCsN-0000db-HF for freebsd-fs@freebsd.org; Tue, 10 Apr 2007 11:42:59 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Apr 2007 11:42:59 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Apr 2007 11:42:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Tue, 10 Apr 2007 11:42:48 +0200 Lines: 35 Message-ID: References: <20070328100536.S6916@besplex.bde.org> <20070330062726.I2388@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig75FCAF2FA895EF3969DECB66" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.10 (X11/20060911) In-Reply-To: <20070330062726.I2388@besplex.bde.org> X-Enigmail-Version: 0.94.2.0 Sender: news Subject: Re: gvirstor & UFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2007 09:43:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig75FCAF2FA895EF3969DECB66 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Bruce Evans wrote: > Apparently it get past the media size check in g_io_check() to give > ENOSPC instead of EIO because g_io_check() only checks the virtual > size. To support virtual overcommitted media, it is necessary for > file systems to either do a physical check whenever they allocate a Ok, what about this: What would happen if I "stall" the IO ops? When I=20 get into the ENOSPC situation (which can happen only during BIO_WRITE),=20 I can add the request in an internal queue, and process it only when I=20 reliably determine that a new physical provider is added (which I can)? Would it interact badly with soft-updates timeouts? --------------enig75FCAF2FA895EF3969DECB66 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGG1wYldnAQVacBcgRAsZPAKDgzKZH9BzOuL3T6+fhK0aEMKn5fQCfThE9 IjgdqdzICFyNJg53NcMWGlw= =E+o3 -----END PGP SIGNATURE----- --------------enig75FCAF2FA895EF3969DECB66--