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@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
