Re: Is there conflicts between gmirror and a quota enabled filesystem?

On Wed, Nov 29, 2006 at 05:54:40AM -0800, Jason Vance wrote:
Posted Monday Nov 27th.

Is there a known conflict between gmirror and a quota enabled filesystem?

----

I have a FreeBSD 5.5-STABLE box that is setup with a gmirror RAID 1 using
two identical harddrives.

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=YES' and 'check_quotas=NO' to the
/etc/rc.conf file thinking i can get it to build the quota table on the fly
instead of it doing that at boot time.

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 the
various services via telnet to their port, but none of them respond.

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.

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.

Attachment: pgpJvH52tqZ1Q.pgp
Description: PGP signature