[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[linux-lvm] Re: DQUOT_SYNC undefined in XFS CVS kernel (was: Can't build CVS



Had this as well.

On Mon, 1 Apr 2002 jtrostel snapserver com wrote:

> 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
>
>
>




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]