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.
pgpuL02EIPQ9e.pgp
Description: PGP signature
