Red Hat Bugzilla – Bug 851158
[xfs/xfsdump] The core.projid_hi is lost in dump/restore process
Last modified: 2013-02-25 08:49:37 EST
Created attachment 606518 [details]
The test script I used to find this.
Description of problem:
When a projid32bit enabled xfs fs is dumped and then restored to a different location (again with the projid32bit functionality enabled), the core.projid_hi value is not copied to the new location resulting in incorrect 16bit project quota id.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create 32bit project quota enabled xfs filesystem
2. Dump the filesystem
3. Restore the filesystem, check the 32bit project quota id
The core.projid_hi is not copied resulting in 16bit project quota ids.
The dump and restore preserve the 32bit project quota ids.
The fact that the core.projid_hi is thrown away in dump/restore cycle was found by the examination of the original and restored fs with xfs_db. You just need to know the inode number of the project quota file:
xfs_db -c "inode <ino>" -c "print core.projid_lo" -c "print core.projid_hi" <device>
You can notice that the core.projid_hi is 0 in the restored filesystem.
Patch for this sent upstream, pending review:
This is actually fixed in current rhel7 xfsdump/xfsprogs/kernel packages.