public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH] xfs_repair: check and repair quota metadata
Date: Mon, 7 May 2018 11:44:00 -0500	[thread overview]
Message-ID: <bee0bca3-fb1c-13a0-0dfb-ba1cd66662be@redhat.com> (raw)
In-Reply-To: <20180507163242.GZ26569@magnolia>

On 5/7/18 11:32 AM, Darrick J. Wong wrote:

>> diff --git a/libxfs/xfs_quota_defs.h b/libxfs/xfs_quota_defs.h
>> index bb1b13a9..067475e2 100644
>> --- a/libxfs/xfs_quota_defs.h
>> +++ b/libxfs/xfs_quota_defs.h
>> @@ -30,6 +30,8 @@
>>  typedef uint64_t	xfs_qcnt_t;
>>  typedef uint16_t	xfs_qwarncnt_t;
>>  
>> +#define XFS_DQUOT_CLUSTER_SIZE_FSB (xfs_filblks_t)1
> 
> Requires a kernel patch, right? :)

oh derp, I'll move that elsewhere, maybe the non-priv userspace
libxfs header, I'll see.


>> diff --git a/repair/incore.h b/repair/incore.h
>> index fd66084f..78a0ed30 100644
>> --- a/repair/incore.h
>> +++ b/repair/incore.h
>> @@ -222,13 +222,16 @@ int		count_bcnt_extents(xfs_agnumber_t);
>>  #define XR_INO_RTDATA	2		/* realtime file */
>>  #define XR_INO_RTBITMAP	3		/* realtime bitmap inode */
>>  #define XR_INO_RTSUM	4		/* realtime summary inode */
>> -#define XR_INO_DATA	5		/* regular file */
>> -#define XR_INO_SYMLINK	6		/* symlink */
>> -#define XR_INO_CHRDEV	7		/* character device */
>> -#define XR_INO_BLKDEV	8		/* block device */
>> -#define XR_INO_SOCK	9		/* socket */
>> -#define XR_INO_FIFO	10		/* fifo */
>> -#define XR_INO_MOUNTPOINT 11		/* mountpoint */
>> +#define XR_INO_UQUOTA	5		/* user quota inode */
>> +#define XR_INO_GQUOTA	6		/* group quota inode */
>> +#define XR_INO_PQUOTA	7		/* project quota inode */
> 
> /me wonders, is there an advantage/requirement to insert the three quota
> inode types in the middle of the range instead of tacking them on the
> end?
> 
> Anyway the rest mostly looks ok to me.

Probably not, I was grouping the internal special inodes together IIRC, but
happy just move them to the end if that's preferable.

-Eric


  reply	other threads:[~2018-05-07 16:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-07 14:20 [PATCH] xfs_repair: check and repair quota metadata Eric Sandeen
2018-05-07 16:32 ` Darrick J. Wong
2018-05-07 16:44   ` Eric Sandeen [this message]
2018-05-07 16:59     ` Darrick J. Wong
2018-05-07 23:28   ` Dave Chinner
2018-05-07 23:30     ` Eric Sandeen
2018-05-07 23:43 ` [PATCH V2] " Eric Sandeen
2018-05-07 23:54   ` Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bee0bca3-fb1c-13a0-0dfb-ba1cd66662be@redhat.com \
    --to=sandeen@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox