*** Bug 1309501 has been marked as a duplicate of this bug. ***

https://access.redhat.com/solutions/2120061
This response states:

"RHEL7 is using XFS v5 because xfsprogs-3.2.x uses it as default. xfs filesystem created with -m crc=1 is a production ready feature from RHEL 7.1 and onwards."

Unfortunately that is not completely correct, by default mkfs.xfs will create a V4 xfs file system. 

It would be great to get a V5 xfs during install also.

Thanks for the heads up, I've added a comment to that solution, I'll see if I can get it fixed.

(In reply to Eric Sandeen from comment #0)
> We've been shipping metadata-crc capable xfsprogs since RHEL7 GA, but have
> not yet turned them on.  There are good reasons to do so now, and they have
> been default upstream for quite some time.  Let's rebase xfsprogs to
> upstream, and gain this capability.

NOTE: I do not know much about this feature yet.  However, my initial thoughts are as follows.  It would be good to know what the "good reasons" are to change the default now.  I'm nervous about it and not sure customers have requested it specifically.  However, if we know of data corruption cases which would have been avoided should this been enabled we can say they implicitly might want this.  I'm sure there's data safety upsides but likely at least some sensitive customers will see performance hit.  There's also the possible further complication with the new 'finobt'.  This can all be handled and I'm not saying we should not do this but I'm voicing my concerns here from support perspective.

Ok, this could be a long list.  We went from 3.2.2 to 4.5.0, so I'll stick to the highlights.

Notable things from the upstream changelogs:

Metadata CRCs, free inode btrees, and directory entry filetypes are now enabled by default.  To replicate the older mkfs on-disk format used in prior RHEL7 releases, use the "-m crc=0 -n ftype=0" options on the mkfs.xfs commandline.

The GETNEXTQUOTA interface is implemented in xfs_quota.  This allows fast iteration over all on-disk quotas even when the number of entries in the user database is extremely large.

The RHEL7.3 kernel rpm requires this version of xfsprogs, because the new default on-disk format requires special handling of log cycle numbers during xfs_repair, which is provided in this release.

(In reply to Eric Sandeen from comment #10)
> Ok, this could be a long list.  We went from 3.2.2 to 4.5.0, so I'll stick
> to the highlights.
> 
> Notable things from the upstream changelogs:
> 
> Metadata CRCs, free inode btrees, and directory entry filetypes are now
> enabled by default.

IIRC, the free inode btree feature is not enabled by default in latest RHEL7.3 xfsprogs

[root@dhcp-66-87-213 sanity]# uname -a
Linux dhcp-66-87-213.rhts.eng.nay.redhat.com 3.10.0-470.el7.x86_64 #1 SMP Fri Jul 15 18:32:03 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux
[root@dhcp-66-87-213 sanity]# rpm -q xfsprogs
xfsprogs-4.5.0-5.el7.x86_64
[root@dhcp-66-87-213 sanity]# mkfs.xfs -f /dev/vda6
meta-data=/dev/vda6              isize=512    agcount=4, agsize=589824 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0, sparse=0
data     =                       bsize=4096   blocks=2359296, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Yes, finobt=0 by default :)

Fixed - thanks Eryu!

-Eric

XFS crc is enabled as default on xfsprogs-4.5.0-6.el7:
# mkfs.xfs -d name=file.img,file=1,size=1g
meta-data=file.img               isize=512    agcount=4, agsize=65536 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0, sparse=0
data     =                       bsize=4096   blocks=262144, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

And crc isn't enabled as default on xfsprogs-3.2.2-2.el7
# mkfs.xfs -d name=file.img,file=1,size=1g
meta-data=file.img               isize=256    agcount=4, agsize=65536 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=0        finobt=0
data     =                       bsize=4096   blocks=262144, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

So verified this bug. And due to this bug do rebase from xfsprogs-3.2 to xfsprogs-4.5, so I've done XFS regression test to make sure there's no regression bug bring in by this change.

(I think we don't need to write a test case to cover this bug.)

Thanks,
Zorro

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2431.html