| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: xfsdump questions, Stevie Trujillo |
|---|---|
| Next by Date: | Re: XFS corruption, Dave Chinner |
| Previous by Thread: | Re: weird quota issue, Weber, Charles (NIH/NIA/IRP) [C] |
| Next by Thread: | RE: weird quota issue, Weber, Charles (NIH/NIA/IRP) [E] |
| Indexes: | [Date] [Thread] [Top] [All Lists] |