From owner-freebsd-stable@FreeBSD.ORG Wed Nov 29 14:25:21 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E947116A403 for ; Wed, 29 Nov 2006 14:25:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id E43DF43CA3 for ; Wed, 29 Nov 2006 14:25:17 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id kATEPC5X068903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Nov 2006 16:25:13 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id kATEPCFj064700; Wed, 29 Nov 2006 16:25:12 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id kATEPBup064699; Wed, 29 Nov 2006 16:25:11 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 29 Nov 2006 16:25:11 +0200 From: Kostik Belousov To: Jason Vance Message-ID: <20061129142511.GE69556@deviant.kiev.zoral.com.ua> References: <20061129120046.8999F16A65C@hub.freebsd.org> <033101c713bd$eac76030$18f48a59@Uhura> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ns7jmDPpOpCD+GE/" Content-Disposition: inline In-Reply-To: <033101c713bd$eac76030$18f48a59@Uhura> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=1.4 required=5.0 tests=SPF_NEUTRAL, UNPARSEABLE_RELAY autolearn=no version=3.1.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on fw.zoral.com.ua Cc: freebsd-stable@freebsd.org Subject: Re: Is there conflicts between gmirror and a quota enabled filesystem? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2006 14:25:21 -0000 --Ns7jmDPpOpCD+GE/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 29, 2006 at 05:54:40AM -0800, Jason Vance wrote: > Posted Monday Nov 27th. >=20 > Is there a known conflict between gmirror and a quota enabled filesystem? >=20 > ---- >=20 > I have a FreeBSD 5.5-STABLE box that is setup with a gmirror RAID 1 using > two identical harddrives. >=20 > I installed quotas on the filesystem by enabling it 'options QUOTA' and > rebuilding the kernel. I added userquota to the /etc/fstab for the /usr > partition and I added 'enable_quotas=3DYES' and 'check_quotas=3DNO' to the > /etc/rc.conf file thinking i can get it to build the quota table on the f= ly > instead of it doing that at boot time. >=20 > The system boots up but as soon as I do any disk access ie 'repquota -a' = or > write a file to the harddrive, the system hangs. I can still connect to t= he > various services via telnet to their port, but none of them respond. >=20 > Now that I've disabled quotas I am able to use the system however fsck has > reported many various file corruptions and destroyed some of my important > system files. >=20 > Is there a known conflict between gmirror and a quota enabled filesystem? > How can I properly set these up? I think this has nothing to do with gmirror. It's the situation described in PR kern/30958. The actual problem is the following call sequence: some process (it may be even a syncer) tries to write the quota (for instance, syncer called ffs_sync, that calls qsync(), that calls dqsync()). dqsync() issues VOP_WRITE() on the quota file, while locked the corresponding dquot. Since file needs to be extended, ffs_balloc_* is entered. There, call to ffs_alloc checks for quota of the owner of the quota file, entering chkdq. This leads to deadlock, since chkdq waits while dqout becomes unlocked. I believe that this scenario is fixed in my mp-safe quota patch. See http://people.freebsd.org/~kib/quotagiant for the patch against CURRENT. As workaround, use quotacheck before enabling quota. --Ns7jmDPpOpCD+GE/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFbZhGC3+MBN1Mb4gRAgudAKCXR5FpYkS4BbxaCItiHq1GlKVaTQCgm5cD sXa/Jd8g9fMTZJQ+kLME9D0= =qg3z -----END PGP SIGNATURE----- --Ns7jmDPpOpCD+GE/--