Date: Mon, 21 Aug 2000 19:15:57 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: David Kirchner <dpk@nwserv.com> Cc: freebsd-hackers@freebsd.org Subject: Re: quotacheck on a live filesystem; safe? (fwd) Message-ID: <Pine.NEB.3.96L.1000821190518.89810H-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.21.0008100749010.77341-100000@web2.sea.nwserv.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Due to the locking involved in ufs_quota.c's management of the quota files, I believe it may be possible to get a deadlock when modifying the quota from userland. I haven't thought through all the details yet, and am not familiar with the quotacheck.c code, but there are some related deadlock conditions in the extended attribute code as it uses backing files in much the same way. In essence, the UFS code holds onto an extra reference to the quota record file as part of the file system mount structure. When it needs to commit quota updates to disk, it acquires a vnode lock for the record file. However, this is not done using the locking protocol -- i.e., the locking order may not be maintained. The caller to ufs_readwrite() may already hold the lock on another file; I'm not sure how rigorously the quota code checks for this type of situation, but if you are getting either hangs during direct quota file modification, or lock manager panics, that could be the source. I believe quotacheck.c attempts to directly access the backing file, in which case such a deadlock could arise. The quotactl interface appears to support a call to set/get quota settings/usage, which should be used to manipulate quotas -- never direct quota backing file access. I make no promise about the accuracy of my claims about the existing quotacheck implementation, but that might be a place to start looking, and you can certainly imagine problems coming about as a result. You might also be able to imagine that direct user access to the quota backing files could be used to bottleneck or entirely block write access to the file system, due to locking requirements. In the extended attribute implementation, I generally recommend that backing files be stored in a directory inaccessible to non-administrative users, as the ability to hold vnode locks for the file (i.e., long vop_read/write calls) could impact performance substantially, or allow a deadlock to arise/be engineered. Robert Watson On Thu, 10 Aug 2000, David Kirchner wrote: > I've searched the archives and I've seen this question asked a few other > times, but I did not see any response. Does anyone know the answer? > > ---------- Forwarded message ---------- > Date: Wed, 9 Aug 2000 14:15:17 -0700 (PDT) > From: David Kirchner <dpk@dpk.net> > To: freebsd-questions@FreeBSD.ORG > Subject: quotacheck on a live filesystem; safe? > > > Hi, > > I've been reading over source for quotacheck and ufs_quota.c and so far I > have not found a reason why running quotacheck on a live filesystem would > cause anything but inconsistencies in the quota.user file. Is this an > incorrect belief? > > >From what I understand: > > the quota.user file is used as a storage for quota information between > boots and by the various userland quota reporting utilities. The kernel > maintains an idea of the quota in memory, and commits it to disk when > necessary. > > If this is correct, then I could expect, at worst, someone's quota to be > invalid if the machine crashes while quotacheck is running and their files > are being modified? > > Thanks, > David Kirchner <dpk@dpk.net> > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" 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-hackers" 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.1000821190518.89810H-100000>