Sorry.... I should have been paying attention... I too found this last week
when I was updating our XFS builds. I also just changed the DQUOT_SYNC(dev) to
DQUOT_SYN_DEV(dev) and have not noticed any more strange manifestations from
that.
So... there's at least one more data point for you.
On 01-Apr-2002 Nathan Scott wrote:
> On Fri, Mar 29, 2002 at 10:26:41PM +1000, Adrian Head wrote:
>> I have also run into the XFS CVS kernel compile failing because of an
>> undefined DQUOT_SYNC.
>>
>> Using the information given by Nathan I have tracked down the offending
>> patch
>> that causes the problems. In my case it was the LVM VFS-lock patch from the
>> Sistina LVM project. What they seem to do is use DQUOT_SYNC to force the
>> writing of cached Quota infomation before they lock the VFS during snapshot
>> creation. It would also seem that EVMS does the same thing.
>
> Aha, thanks for tracking this down Adrian.
>
>> I expect that the XFS CVS kernel tree is actually ahead of the standard
>> 2.4.18 kernel tree in this respect so we'll have to wait until 2.4.19 is
>> released with the updated API's before other projects update their kernel
>> patches.
>
> Yes, the XFS trees contain all of the quota patches from:
>ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/v2.4/
>
> I wouldn't expect these patches to be in 2.4.19 -- they are
> not in 2.5 yet and I think Jan is concentrating on that step
> first.
>
>> Grep'ing through the kernel I have not been able to find any comments or
>> explanations regarding this - so I have assumed that DQUOT_SYNC can be
>> changed to DQUOT_SYNC_DEV without problems.
>
> Yes, by my understanding of the VFS quota subsystem that would
> be the correct thing to do.
>
>> After making that change the kernel compiles cleanly and boots. I'm unsure
>> as yet if I have done the correct thing here. Hopefuly someone will be able
>> to help us out and correct me if I'm incorrect.
>
> I believe your change is correct, I've CC'd Jan in case there is
> anything that I've overlooked.
>
> cheers.
>
>
>> The offending part of the VF-lock patch follows below:
>>
>> Index: linus.21/fs/buffer.c
>> --- linus.21/fs/buffer.c Mon, 28 Jan 2002 09:51:50 -0500 root
>> (linux/i/45_buffer.c 1.5.2.6 644)
>> +++ linus.21(w)/fs/buffer.c Mon, 28 Jan 2002 11:54:36 -0500 root
>> (linux/i/45_buffer.c 1.5.2.6 644)
>> @@ -361,6 +361,34 @@
>> fsync_dev(dev);
>> }
>>
>> +int fsync_dev_lockfs(kdev_t dev)
>> +{
>> + /* you are not allowed to try locking all the filesystems
>> + ** on the system, your chances of getting through without
>> + ** total deadlock are slim to none.
>> + */
>> + if (!dev)
>> + return fsync_dev(dev) ;
>> +
>> + sync_buffers(dev, 0);
>> +
>> + lock_kernel();
>> + /* note, the FS might need to start transactions to
>> + ** sync the inodes, or the quota, no locking until
>> + ** after these are done
>> + */
>> + sync_inodes(dev);
>> + DQUOT_SYNC(dev);
>> ^<==== ****All I did was to change this to
>> DQUOT_SYNC_DEV(dev);****
>> + /* if inodes or quotas could be dirtied during the
>> + ** sync_supers_lockfs call, the FS is responsible for getting
>> + ** them on disk, without deadlocking against the lock
>> + */
>> + sync_supers_lockfs(dev) ;
>> + unlock_kernel();
>> +
>> + return sync_buffers(dev, 1) ;
>> +}
>> +
>> asmlinkage long sys_sync(void)
>> {
>> fsync_dev(0);
>>
>>
>> On Thu, 28 Mar 2002 07:30, Nathan Scott wrote:
>> > Hello,
>> >
>> > On Wed, Mar 27, 2002 at 09:45:48AM +0100, Bas wrote:
>> > > Hi,
>> > >
>> > > It's not possible for me to build the kernel mentioned above. I saw the
>> > > new qouta options and suspect it has something to do with it, but I'm
>> > > not
>> > > sure.
>> > >
>> > > Building everything goes fine, but at the end of the run it's not able
>> > > to
>> > > produce a kernel because of DQUOT_SYNC. I don't have the exact error
>> > > here.
>> >
>> > Hmm... 20020327 - that's yesterday. DQUOT_SYNC doesn't appear in
>> > the source at all anymore (for awhile now), so I suspect the problem
>> > must be at your end. Try getting a fresh CVS copy and/or "make clean".
>> > [ The other patches you mentioned should not have anything to do with
>> > this problem. ]
>> >
>> > $ find . -type f | xargs fgrep DQUOT_SYNC
>> > ./fs/buffer.c: DQUOT_SYNC_SB(sb);
>> > ./fs/buffer.c: DQUOT_SYNC_DEV(dev);
>> > ./include/linux/quotaops.h:#define DQUOT_SYNC_DEV(dev)
>> > sync_dquots_dev(dev, -1) ./include/linux/quotaops.h:#define
>> > DQUOT_SYNC_SB(sb) sync_dquots_sb(sb, -1)
>> > ./include/linux/quotaops.h:#define DQUOT_SYNC_DEV(dev) do
>> > { } while(0) ./include/linux/quotaops.h:#define DQUOT_SYNC_SB(sb)
>> > do { } while(0) $
>> >
>> > FWIW, DQUOT_SYNC used to come from include/linux/quotaops.h
>> > too, and its definition was also dependent on CONFIG_QUOTA.
>> > The reason you'd be getting an unresolved symbol would be a
>> > file referencing DQUOT_SYNC wasn't #include'ing quotaops.h;
>> > but thats all by-the-by - the real problem is related to the
>> > source you're using I suspect - it certainly doesn't match
>> > CVS of yesterday.
>> >
>> > cheers.
>>
>> --
>> Adrian Head
>>
>> (Public Key available on request.)
>
> --
> Nathan
--
John M. Trostel
Senior Software Engineer
Quantum Corp. / NASD
jtrostel@xxxxxxxxxxxxxx