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@snapserver.com _______________________________________________ linux-lvm mailing list linux-lvm@sistina.com http://lists.sistina.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html