Re: [PATCH] xfsdump: save & restore 32-bit projids

From: Ben Myers <bpm@sgi.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: "Bill Kendall" <wkendall@sgi.com>,
	=?UTF-8?B?QXJrYWRpdXN6IE1pxZtraWV3aWM=?=@oss.sgi.com,
	"Boris Ranto" <branto@redhat.com>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH] xfsdump: save & restore 32-bit projids
Date: Tue, 18 Sep 2012 15:44:43 -0500	[thread overview]
Message-ID: <20120918204443.GV3274@sgi.com> (raw)
In-Reply-To: <503ABD37.7090006@redhat.com>

Hey Eric,

On Sun, Aug 26, 2012 at 07:20:07PM -0500, Eric Sandeen wrote:
> Current xfsdump/xfsrestore only recognize the lower 16 bits of the projid.
> With this patch, the full 32 bits are dumped & restored.
> 
> Reported-by: Boris Ranto <branto@redhat.com>
> Cc: Arkadiusz Miśkiewicz <arekm@maven.pl>
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> ---
> 
> This also adds a definition for bs_forkoff, but I don't think
> that is something which should get saved & restored, correct?
> 
> TBH I've done very little hacking on xfsdump.  I think this
> requires a new version, but not sure.  This seems to work but
> may need sanity checks & fixups.  And, of course, an xfstest.

I have two versioned dump files ~/dump-v3 and ~/dump-v4.  v3 is prior to your
patch and v4 was with this patch.

Here is a version 3 xfsrestore of a version 4 dump:

~/xfsdump # xfsrestore -f ~/dump-v4  /mnt/scratch
xfsrestore: using file dump (drive_simple) strategy
xfsrestore: version 3.1.0 (dump format 3.0) - type ^C for status and control
			   ^^^^^^^^^^^^^^^ version 3
xfsrestore: searching media for dump
xfsrestore: ERROR: unrecognized media file header version (4)
xfsrestore: restore complete: 0 seconds elapsed
xfsrestore: Restore Summary:
xfsrestore:   stream 0 /root/dump-v4 OK (success)
xfsrestore: Restore Status: SUCCESS			<---- FAIL?

We should consider whether failure is the correct thing to do when trying to
restore from an incompatible dump file.  That is not a problem with this patch.

Now a version 4 xfsrestore with a version 3 dump:

~/xfsdump # xfsrestore -f ~/dump-v3  /mnt/scratch
xfsrestore: using file dump (drive_simple) strategy
xfsrestore: version 3.1.0 (dump format 4.0) - type ^C for status and control
			   ^^^^^^^^^^^^^^^ version 4, looks good
xfsrestore: searching media for dump
xfsrestore: examining media file 0
xfsrestore: dump description: 
xfsrestore: hostname: foo
xfsrestore: mount point: /mnt/scratch
xfsrestore: volume: /dev/sdb1
xfsrestore: session time: Tue Sep 18 14:45:36 2012
xfsrestore: level: 0
xfsrestore: session label: "k"
xfsrestore: media label: "k"
xfsrestore: file system id: 983f85f2-9a11-460d-a276-9aec42fbd8f7
xfsrestore: session id: 4fbfbd3d-6f4a-4ad5-909b-bdf4742e849d
xfsrestore: media id: 41f8e77c-7b93-49c5-a9ed-c66a391778e7
xfsrestore: using online session inventory
xfsrestore: searching media for directory dump
xfsrestore: reading directories
xfsrestore: 4 directories and 9 entries processed
xfsrestore: directory post-processing
xfsrestore: restoring non-directory files
xfsrestore: restore complete: 0 seconds elapsed
xfsrestore: Restore Summary:
xfsrestore:   stream 0 /root/dump-v3 OK (success)
xfsrestore: Restore Status: SUCCESS

So the behavior with respect to versioning is:  You can restore from dumps that
have a smaller or equal dump version than your xfsrestore, but not from dumps
with versions greater than your xfsrestore.  Now I'd like to see the behavior
with some project ids set and a version 3 dump with version 4 xfsrestore.

A version 4 xfsrestore with a version 3 dump:

~/xfsdump # xfsrestore -f ~/dump-v3-3 /mnt/scratch/restore/
xfsrestore: using file dump (drive_simple) strategy
xfsrestore: version 3.1.0 (dump format 4.0) - type ^C for status and control
xfsrestore: searching media for dump
xfsrestore: examining media file 0
xfsrestore: dump description:
xfsrestore: hostname: foo
xfsrestore: mount point: /mnt/scratch
xfsrestore: volume: /dev/sdb1
xfsrestore: session time: Tue Sep 18 15:18:16 2012
xfsrestore: level: 0
xfsrestore: session label: "l"
xfsrestore: media label: "l"
xfsrestore: file system id: 983f85f2-9a11-460d-a276-9aec42fbd8f7
xfsrestore: session id: 9ad2909c-3542-428b-9f73-0bf207b77888
xfsrestore: media id: 529e47bc-b6fa-427c-a0f5-dcd4c9707adc
xfsrestore: using online session inventory
xfsrestore: searching media for directory dump
xfsrestore: reading directories
xfsrestore: 4 directories and 8 entries processed
xfsrestore: directory post-processing
xfsrestore: restoring non-directory files
xfsrestore: project quota information written to '/mnt/scratch/restore//xfsdump_quotas_proj'
xfsrestore: use 'xfs_quota' to restore quotas
xfsrestore: restore complete: 0 seconds elapsed
xfsrestore: Restore Summary:
xfsrestore:   stream 0 /root/dump-v3-3 OK (success)
xfsrestore: Restore Status: SUCCESS

And a version 4 xfsrestore with a version 4 dump:

~/xfsdump # xfsrestore -f ~/dump-v4-3 /mnt/scratch/restore2
xfsrestore: using file dump (drive_simple) strategy
xfsrestore: version 3.1.0 (dump format 4.0) - type ^C for status and control
xfsrestore: searching media for dump
xfsrestore: examining media file 0
xfsrestore: dump description:
xfsrestore: hostname: foo
xfsrestore: mount point: /mnt/scratch
xfsrestore: volume: /dev/sdb1
xfsrestore: session time: Tue Sep 18 15:20:18 2012
xfsrestore: level: 0
xfsrestore: session label: "l"
xfsrestore: media label: "l"
xfsrestore: file system id: 983f85f2-9a11-460d-a276-9aec42fbd8f7
xfsrestore: session id: e5d07daf-3bfc-4ab8-b13c-ad48db813807
xfsrestore: media id: 9d043994-9abb-4fd0-8cc9-eda68c62641c
xfsrestore: using online session inventory
xfsrestore: searching media for directory dump
xfsrestore: reading directories
xfsrestore: 4 directories and 8 entries processed
xfsrestore: directory post-processing
xfsrestore: restoring non-directory files
xfsrestore: project quota information written to '/mnt/scratch/restore2/xfsdump_quotas_proj'
xfsrestore: use 'xfs_quota' to restore quotas
xfsrestore: restore complete: 0 seconds elapsed
xfsrestore: Restore Summary:
xfsrestore:   stream 0 /root/dump-v4-3 OK (success)
xfsrestore: Restore Status: SUCCESS

Here are the files with project quotas:

originals:
~/xfsdump # xfs_io -r -c "lsproj" /mnt/scratch/dumpme/16bit 
projid = 1234
~/xfsdump # xfs_io -r -c "lsproj" /mnt/scratch/dumpme/32bit 
projid = 2123456789

from the v3 dump:
~/xfsdump # xfs_io -r -c "lsproj" /mnt/scratch/restore/dumpme/16bit 
projid = 1234
~/xfsdump # xfs_io -r -c "lsproj" /mnt/scratch/restore/dumpme/32bit 
projid = 24853		<--- note that it is munged just as in test 287

from the v4 dump:
~/xfsdump # xfs_io -r -c "lsproj" /mnt/scratch/restore2/dumpme/16bit 
projid = 1234
~/xfsdump # xfs_io -r -c "lsproj" /mnt/scratch/restore2/dumpme/32bit 
projid = 2123456789

The code looks good, the xfstest 287 looks good, and the above shows that we
have the desired behavior with respect to dump versioning.

Reviewed-by: Ben Myers <bpm@sgi.com>

Committed to git://oss.sgi.com/xfs/cmds/xfsdump.git, master branch.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs