From owner-freebsd-fs@FreeBSD.ORG Thu Mar 25 10:18:41 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F14B416A4CE for ; Thu, 25 Mar 2004 10:18:41 -0800 (PST) Received: from smtp2.completel.net (smtp2.completel.net [195.167.195.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7E9743D39 for ; Thu, 25 Mar 2004 10:18:40 -0800 (PST) (envelope-from momtchil.momtchev@netasq.com) Received: from smtp.netasq.com (netasq.netasq.com [213.30.137.178] (may be forged)) by smtp2.completel.net (8.12.8/8.12.8) with ESMTP id i2PIIm9q010597 for ; Thu, 25 Mar 2004 19:18:48 +0100 From: Momtchil Momtchev Organization: NETASQ To: freebsd-fs@freebsd.org Date: Thu, 25 Mar 2004 19:19:08 +0000 User-Agent: KMail/1.6.1 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200403251919.08564.momtchil.momtchev@netasq.com> Subject: Problem (potential bug) in the vnode disk driver, stable branch X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2004 18:18:42 -0000 Hello, We've stumbled on what appears to be a bug in the vnode disk driver. It=20 happens rarely and we aren't able to reproduce it atm, but we've seen it=20 already a few times on different kernels, compiled with different options. If you can read russian, there's also a brief description of what appears = to=20 be exactly the same problem at=20 http://www.j2.ru/frozenfido/ru.unix.bsd/89061df31001.html. Theirs is on=20 =46reeBSD 4.3, we are running FreeBSD 4.9. What happens is that after mounting a file as a filesystem through the vn= =20 driver, everything will run fine, then eventually (after a few days, weeks = or=20 even months) the filesystem is going to get "disconnected" in a strange way= =20 with every attempt to access it returning an I/O error. vnconfig will report "device not configured": #/usr/sbin/vnconfig -c /dev/vn0c /somefile vnconfig: /dev/vn0c: Device not configured #vnconfig -u /dev/vn0c vnconfig: /dev/vn0c: Device not configured umount/mount will fail too. We are still trying to find a way to reliably reproduce the problem in ord= er=20 to fill a standard bug report. ATM we don't have any idea what could trigger it. The main problem is that it happens very rarely and we can't really afford= to=20 run a kernel with all the debugging enabled on thousands of hosts (to catch= =20 the few which will crash). Anyone seen this before? Any comments will be appreciated. =2D- Momtchil Momtchev, R&D Engineer Netasq - Secure Internet Connectivity http://www.netasq.com T=E9l : +33 320 619 630 =46ax : +33 320 619 639