Very Computer

> >>>1) quotactl(Q_SYNC, NULL) is supposed to sync all quotas.  This fails.
> >>>The manpage still documents it.  Is this still valid?  I think it needs
> >>>to be..

> >  It should work... I'll have a look at it. For XFS and other fses it might
> >noop but it shouldn't fail.

> Right, it should just loop and noop where needed.  Maybe something like:

>         spin_lock(&sb_lock);
>         list_for_each(p, &super_blocks) {
>                 sb = sb_entry(p);
>                 if (sb->s_qcop->quota_sync)
>                         sb->s_qcop->quota_sync(sb, type);
>                 }
>         spin_unlock(&sb_lock);
>         return 0;

> I appreciate you looking into this one.

> >>I believe the fundamental changes to the API were made to support
> >>32 bit uid's/gid's in the VFS quota implementation and changes to
> >>the ondisk quota file format.  Its my belief that the new versions
> >>of the tools could work with either new or old kernels, best check
> >>with Jan on that one (nothing to do with XFS).

> >  Right. And to the binary compatibility: Linux is not supposed to
> >maintain binary compatibily between major kernel releases (eg.
> >2.2->2.4) and quota changes were accepted in 2.5.

> OK, but what of the 2.4 backport?  Adding XFS to a 2.4.x kernel breaks
> binary compatibility.  It seems to me that gratuitously changing values
> so as to gurantee broken compatibility is inane.

> I guess I'll have to deal with this aspect of it.  If Q_SYNC for NULL
> works, then I can get working systems back with a recompile and new
> headers.  Uggh.  Not nice to do to me in an update of a backport.

> thanks for the info.

> Tim
> --
> Tim Hockin
> Systems Software Engineer
> Sun Microsystems, Linux Kernel Engineering