Bug 1309498 - Rebase xfsprogs; enable metadata CRCs by default
Summary: Rebase xfsprogs; enable metadata CRCs by default
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: xfsprogs
Version: 7.3
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Eric Sandeen
QA Contact: Zorro Lang
Milan Navratil
URL:
Whiteboard:
: 1309501 (view as bug list)
Depends On:
Blocks: 1306029 1340553
TreeView+ depends on / blocked
 
Reported: 2016-02-18 00:13 UTC by Eric Sandeen
Modified: 2016-11-04 06:24 UTC (History)
9 users (show)

Fixed In Version: xfsprogs-4.5.0-1.el7
Doc Type: Release Note
Doc Text:
_xfsprogs_ rebased to version 4.5.0 The _xfsprogs_ packages have been upgraded to upstream version 4.5.0, which provides a number of bug fixes and enhancements over the previous version. The Red Hat Enterprise Linux 7.3 kernel RPM requires the upgraded version of _xfsprogs_ because the new default on-disk format requires special handling of log cycle numbers when running the *xfs_repair* utility. Notable changes include: * Metadata cyclic redundancy checks (CRCs) and directory entry file types are now enabled by default. To replicate the older *mkfs* on-disk format used in earlier versions of Red Hat Enterprise Linux 7, use the "-m crc=0 -n ftype=0" options on the *mkfs.xfs* command line. * The `GETNEXTQUOTA` interface is now implemented in *xfs_quota*, which allows fast iteration over all on-disk quotas even when the number of entries in the user database is extremely large. Also, note the following differences between upstream and Red Hat Enterprise Linux 7.3: * The experimental sparse inode feature is not available. * The free inode btree (finobt) feature is disabled by default to ensure compatibility with earlier Red Hat Enterprise Linux 7 kernel versions.
Clone Of:
Environment:
Last Closed: 2016-11-04 06:24:00 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2431 normal SHIPPED_LIVE xfsprogs bug fix and enhancement update 2016-11-03 14:00:51 UTC
Red Hat Knowledge Base (Article) 2362141 None None None 2016-06-10 20:16:24 UTC

Description Eric Sandeen 2016-02-18 00:13:47 UTC
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.

Comment 2 Eric Sandeen 2016-02-18 03:37:58 UTC
*** Bug 1309501 has been marked as a duplicate of this bug. ***

Comment 3 Dragan 2016-02-29 20:19:23 UTC
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.

Comment 4 Eric Sandeen 2016-02-29 20:25:50 UTC
Thanks for the heads up, I've added a comment to that solution, I'll see if I can get it fixed.

Comment 8 Dave Wysochanski 2016-06-10 20:41:05 UTC
(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.

Comment 10 Eric Sandeen 2016-07-21 23:16:38 UTC
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.

Comment 11 Eryu Guan 2016-07-22 03:21:36 UTC
(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 :)

Comment 12 Eric Sandeen 2016-07-22 05:12:21 UTC
Fixed - thanks Eryu!

-Eric

Comment 15 Zorro Lang 2016-08-20 04:38:25 UTC
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

Comment 22 errata-xmlrpc 2016-11-04 06:24:00 UTC
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


Note You need to log in before you can comment on or make changes to this bug.