xfs
[Top] [All Lists]

Re: weird quota issue

To: "Weber, Charles (NIH/NIA/IRP) [C]" <weberc@xxxxxxxxxxxxxxx>
Subject: Re: weird quota issue
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 23 Dec 2014 11:32:37 +1100
Cc: "xfs@xxxxxxxxxxx" <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <2F3F57BB-59EA-4FF9-9254-6A598DE7AC46@xxxxxxxxxxxxxxx>
References: <3BD1EE39-8C26-4C5B-94B5-492422EECEDA@xxxxxxxxxxxx> <20141222204857.GK24183@dastard> <6F43BF63-A44E-43F6-A184-9AAC10DDDFDF@xxxxxxxxxxxxxxx> <20141222223540.GS15665@dastard> <2F3F57BB-59EA-4FF9-9254-6A598DE7AC46@xxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, Dec 22, 2014 at 05:46:42PM -0500, Weber, Charles (NIH/NIA/IRP) [C] 
wrote:
> I wonder if it is a thin-provision issue? ~40TB allocated by the SAN but 
> setup to not really allocate space until it is claimed by the OS. 
> 
>  xfs_db -c "sb 0" -c p /dev/dm-7
> 
....
> versionnum = 0xb5e4

So the quota bit is set (0x40) hence quotas will attempt to be
enabled.

> uquotino = 131
> gquotino = 0
> qflags = 0

But we have no quota enabled but a user quota inode allocated.
the quota flags would have been written to zero by the initial
failure, so this implies that reading the  user quota inode failed.
Output of 'xfs_db -c "inode 131" -c p /dev/dm-7', please?

-Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>