Date: Tue, 22 Aug 2000 14:32:08 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Chris Jones <chrisx77@hotmail.com> Cc: freebsd-fs@FreeBSD.org Subject: Re: Inode/DQuot locking problem with vnode disk Message-ID: <Pine.NEB.3.96L.1000822142844.5556D-100000@fledge.watson.org> In-Reply-To: <F72lkDTM9wGmAf0Mjka000006c2@hotmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Any chance I could get you to file a problem report for this, using send-pr? I am interested in the problem, having both some familiarity with the UFS quota/extended attribute implementations, and having worked on the jail code, but won't have a chance to work on this for a week or two due to travel and moving from Maryland to Massachusetts in two weeks. I don't want the problem getting lost in the fray, and the gnats database is a good way of keeping track of this. Forward me a copy of the response you get from gnats (with the PR number) and I'll grab ownership of the problem, assuming no one else solves it first. I'm actually also interested in whether or not the same problem occurs with the UFS extended attribute code: it uses a similar backing file mechanism as the kernel does, and as a result might be subject to the same deadlocks. Yor analysis of the problem sounds good to me, but I'm not sure why it would manifest only in the jail environment -- perhaps some sort of race, or due to locking order starting at the process root vnode. Thanks, On Tue, 22 Aug 2000, Chris Jones wrote: > I am currently trying to get quotas to work inside of a vnode disk > (filesystem in a file (using UFS)). The problem is that I want the quotas > to work inside of a jail which is running with the vnode disk as it's "root" > directory. The problem that I'm having is that after turning on the quotas > (this must be done outside of the jail), if I try to access a file which > already has a quota, or I try to modify the quota using edquota (from inside > of the jail), the process locks. Once the process is locked, there is no > way to kill it, and any subsequent accesses to the vnode disk also locks. > These processes will stop in 1 of 5 different tsleep statements (inode, > chkdq1, chkdq2, chkiq1, or chkiq2). I am assuming that the problems is that > the main filesystem puts a lock on the vnode disk file, and subsequently > tries to lock the indoe inside of the file and is unable b/c of the previous > lock on the vnode disk file. Has anyone else seen this? Any pointers would > be greatly appreciated. Oh, yeah, the version is 4.0-STABLE. > > Thank you, > > Christophe > ________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message > Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000822142844.5556D-100000>