weird quota issue

[Dave Chinner]

On Tue, Dec 23, 2014 at 08:19:20AM +0100, Arkadiusz Miśkiewicz wrote:
> On Tuesday 23 of December 2014, Dave Chinner wrote:
> > On Tue, Dec 23, 2014 at 02:12:15AM +0000, Weber, Charles (NIH/NIA/IRP) [E] 
> wrote:
> > > here you go
> > > 
> > > # xfs_db -c "inode 131" -c p /dev/dm-7
> > 
> > Nothing obviously wrong there, so there's no clear indication of why
> > the quota initialisation failed.
> 
> gquotino should be set to null, setting it via xfs_db should fix the problem

# umount /dev/dm-7
# xfs_db -x -c "sb 0" -c "write gquotino -1" /dev/dm-7

> > uquotino = 131
> > gquotino = 0
> > qflags = 0
> 
> Otherwise we end up with my last problem
> 
> http://oss.sgi.com/archives/xfs/2014-07/msg00121.html
> 
> "- 3.10 kernel is not able to handle case when uquotino == value, gquotino == 
> 0. For 3.10 this case is impossible / should never happen. 3.10 expects 
> (uquotino == value, gquotino == null) or (uquotino == value, gquotino == 
> othervalue) or (uqotinfo == null, gruotino == value) only."
> 
> So I guess 2.6.32 is doing the same.

Except that the problem you saw required running a 3.16 kernel to
trigger the unhandled state. I can't see why a system only running
a 2.6.32 kernel would ever get into this state....

> AFAIK xfs_repair doesn't fix this issue. Not sure.

Certainly not the one that comes with centos 6 - 0 and NULL are both
valid values...

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com