public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Chandan Babu R <chandan.babu@oracle.com>
Cc: cem@kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 22/24] mdrestore: Define mdrestore ops for v2 format
Date: Tue, 23 May 2023 11:06:02 -0700	[thread overview]
Message-ID: <20230523180602.GA11620@frogsfrogsfrogs> (raw)
In-Reply-To: <20230523090050.373545-23-chandan.babu@oracle.com>

On Tue, May 23, 2023 at 02:30:48PM +0530, Chandan Babu R wrote:
> This commit adds functionality to restore metadump stored in v2 format.
> 
> Signed-off-by: Chandan Babu R <chandan.babu@oracle.com>
> ---
>  mdrestore/xfs_mdrestore.c | 209 +++++++++++++++++++++++++++++++++++---
>  1 file changed, 194 insertions(+), 15 deletions(-)
> 
> diff --git a/mdrestore/xfs_mdrestore.c b/mdrestore/xfs_mdrestore.c
> index 615ecdc77..9e06d37dc 100644
> --- a/mdrestore/xfs_mdrestore.c
> +++ b/mdrestore/xfs_mdrestore.c
> @@ -11,7 +11,8 @@ struct mdrestore_ops {
>  	int (*read_header)(void *header, FILE *mdfp);
>  	void (*show_info)(void *header, const char *mdfile);
>  	void (*restore)(void *header, FILE *mdfp, int data_fd,
> -			bool is_target_file);
> +			bool is_data_target_file, int log_fd,
> +			bool is_log_target_file);
>  };
>  
>  static struct mdrestore {
> @@ -148,7 +149,9 @@ restore_v1(
>  	void		*header,
>  	FILE		*mdfp,
>  	int		data_fd,
> -	bool		is_target_file)
> +	bool		is_data_target_file,
> +	int		log_fd,
> +	bool		is_log_target_file)
>  {
>  	struct xfs_metablock	*mbp = header;
>  	struct xfs_metablock	*metablock;
> @@ -203,7 +206,7 @@ restore_v1(
>  
>  	((struct xfs_dsb*)block_buffer)->sb_inprogress = 1;
>  
> -	verify_device_size(data_fd, is_target_file, sb.sb_dblocks,
> +	verify_device_size(data_fd, is_data_target_file, sb.sb_dblocks,
>  			sb.sb_blocksize);
>  
>  	bytes_read = 0;
> @@ -264,6 +267,163 @@ static struct mdrestore_ops mdrestore_ops_v1 = {
>  	.restore = restore_v1,
>  };
>  
> +static int
> +read_header_v2(
> +	void				*header,
> +	FILE				*mdfp)
> +{
> +	struct xfs_metadump_header	*xmh = header;
> +
> +	rewind(mdfp);

Does rewind() work if @mdfp is a pipe?

I suspect the best you can do is read the first 4 bytes in main, pick
the read_header function from that, and have the read_header_v[12] read
in the rest of the header from there.  I use a lot of:

xfs_metadump -ago /dev/sda - | gzip > foo.md.gz
gzip -d < foo.md.gz | xfs_mdrestore -g - /dev/sdb

to store compressed metadumps for future reference.

(Well ok I use xz or zstd, but you get the point.)

> +
> +	if (fread(xmh, sizeof(*xmh), 1, mdfp) != 1)
> +		fatal("error reading from metadump file\n");
> +	if (xmh->xmh_magic != cpu_to_be32(XFS_MD_MAGIC_V2))
> +		return -1;
> +
> +	return 0;
> +}
> +
> +static void
> +show_info_v2(
> +	void				*header,
> +	const char			*mdfile)
> +{
> +	struct xfs_metadump_header	*xmh;
> +	uint32_t			incompat_flags;
> +
> +	xmh = header;
> +	incompat_flags = be32_to_cpu(xmh->xmh_incompat_flags);
> +
> +	printf("%s: %sobfuscated, %s log, %s metadata blocks\n",
> +		mdfile,
> +		incompat_flags & XFS_MD2_INCOMPAT_OBFUSCATED ? "":"not ",
> +		incompat_flags & XFS_MD2_INCOMPAT_DIRTYLOG ? "dirty":"clean",
> +		incompat_flags & XFS_MD2_INCOMPAT_FULLBLOCKS ? "full":"zeroed");
> +}
> +
> +static void
> +restore_v2(
> +	void			*header,
> +	FILE			*mdfp,
> +	int			data_fd,
> +	bool			is_data_target_file,
> +	int			log_fd,
> +	bool			is_log_target_file)
> +{
> +	struct xfs_sb		sb;
> +	struct xfs_meta_extent	xme;
> +	char			*block_buffer;
> +	int64_t			bytes_read;
> +	uint64_t		offset;
> +	int			prev_len;
> +	int			len;
> +
> +	if (fread(&xme, sizeof(xme), 1, mdfp) != 1)
> +		fatal("error reading from metadump file\n");
> +
> +	len = be32_to_cpu(xme.xme_len);
> +	len <<= BBSHIFT;

Do we need to validate xme_addr==0 and xme_len==1 here?

> +
> +	block_buffer = calloc(1, len);
> +	if (block_buffer == NULL)
> +		fatal("memory allocation failure\n");
> +
> +	if (fread(block_buffer, len, 1, mdfp) != 1)
> +		fatal("error reading from metadump file\n");
> +
> +	libxfs_sb_from_disk(&sb, (struct xfs_dsb *)block_buffer);
> +
> +	if (sb.sb_magicnum != XFS_SB_MAGIC)
> +		fatal("bad magic number for primary superblock\n");
> +
> +	if (sb.sb_logstart == 0 && log_fd == -1)
> +		fatal("External Log device is required\n");
> +
> +	((struct xfs_dsb *)block_buffer)->sb_inprogress = 1;
> +
> +	verify_device_size(data_fd, is_data_target_file, sb.sb_dblocks,
> +			sb.sb_blocksize);
> +
> +	if (sb.sb_logstart == 0)
> +		verify_device_size(log_fd, is_log_target_file, sb.sb_logblocks,
> +				sb.sb_blocksize);
> +
> +	bytes_read = 0;
> +
> +	do {
> +		int fd;
> +
> +		if (mdrestore.show_progress &&
> +			(bytes_read & ((1 << 20) - 1)) == 0)
> +			print_progress("%lld MB read", bytes_read >> 20);

Doesn't this miss a progress report if a metadata extent bumps
bytes_read across a MB boundary without actually landing on it?  Say
you've written 1020K, and the next xfs_meta_extent is 8k long.

	if (metadump.show_progress) {
		static int64_t	mb_read;
		int64_t		mb_now = bytes_read >> 20;

		if (mb_now != mb_read) {
			print_progress("%lld MB read", mb_now);
			mb_read = mb_now;
		}
	}

> +
> +		offset = be64_to_cpu(xme.xme_addr) & XME_ADDR_DEVICE_MASK;
> +		offset <<= BBSHIFT;

offset = BBTOB(be64_to_cpu() ... ); ?

Also, I'd have thought that XME_ADDR_DEVICE_MASK is what you use to
decode the device, not what you use to decode the address within a
device.

> +
> +		if (be64_to_cpu(xme.xme_addr) & XME_ADDR_DATA_DEVICE)
> +			fd = data_fd;
> +		else if (be64_to_cpu(xme.xme_addr) & XME_ADDR_LOG_DEVICE)
> +			fd = log_fd;
> +		else
> +			ASSERT(0);

If you instead defined the constants like this:

#define XME_ADDR_DEVICE_SHIFT	54
#define XME_ADDR_DEVICE_MASK	((1ULL << XME_ADDR_DEVICE_SHIFT) - 1)

#define XME_ADDR_DATA_DEVICE	(0 << XME_ADDR_DEVICE_SHIFT)
#define XME_ADDR_LOG_DEVICE	(1 << XME_ADDR_DEVICE_SHIFT)
#define XME_ADDR_RT_DEVICE	(2 << XME_ADDR_DEVICE_SHIFT)

#define XME_ADDR_DEVICE_MASK	(3 << XME_ADDR_DEVICE_SHIFT)

Then the above becomes:

	offset = BBTOB(be64_to_cpu(xme.xme_addr) & XME_ADDR_DADDR_MASK);

	switch (be64_to_cpu(xme.xme_addr) & XME_ADDR_DEVICE_MASK) {
	case XME_ADDR_DATA_DEVICE:
		fd = data_fd;
		break;
	...
	}
> +
> +		if (pwrite(fd, block_buffer, len, offset) < 0)
> +			fatal("error writing to %s device at offset %llu: %s\n",
> +				fd == data_fd ? "data": "log", offset,
> +				strerror(errno));
> +
> +                if (fread(&xme, sizeof(xme), 1, mdfp) != 1) {
> +			if (feof(mdfp))
> +				break;
> +			fatal("error reading from metadump file\n");
> +		}
> +
> +		prev_len = len;
> +		len = be32_to_cpu(xme.xme_len);
> +		len <<= BBSHIFT;
> +		if (len > prev_len) {
> +			void *p;
> +			p = realloc(block_buffer, len);

Would it be preferable to declare an 8MB buffer and only copy contents
in that granularity?  Technically speaking, xme_len == -1U would require
us to allocate a 2TB buffer, wouldn't it?

> +			if (p == NULL) {
> +				free(block_buffer);
> +				fatal("memory allocation failure\n");
> +			}
> +			block_buffer = p;
> +		}
> +
> +		if (fread(block_buffer, len, 1, mdfp) != 1)
> +			fatal("error reading from metadump file\n");
> +
> +		bytes_read += len;
> +	} while (1);
> +
> +	if (mdrestore.progress_since_warning)
> +		putchar('\n');
> +
> +        memset(block_buffer, 0, sb.sb_sectsize);

Tabs not spaces.

> +	sb.sb_inprogress = 0;
> +	libxfs_sb_to_disk((struct xfs_dsb *)block_buffer, &sb);
> +	if (xfs_sb_version_hascrc(&sb)) {
> +		xfs_update_cksum(block_buffer, sb.sb_sectsize,
> +				offsetof(struct xfs_sb, sb_crc));
> +	}
> +
> +	if (pwrite(data_fd, block_buffer, sb.sb_sectsize, 0) < 0)
> +		fatal("error writing primary superblock: %s\n",
> +			strerror(errno));
> +
> +	free(block_buffer);
> +
> +	return;
> +}
> +
> +static struct mdrestore_ops mdrestore_ops_v2 = {
> +	.read_header = read_header_v2,
> +	.show_info = show_info_v2,
> +	.restore = restore_v2,
> +};
> +
>  static void
>  usage(void)
>  {
> @@ -276,11 +436,16 @@ main(
>  	int 		argc,
>  	char 		**argv)
>  {
> -	FILE		*src_f;
> -	int		dst_fd;
> -	int		c;
> -	bool		is_target_file;
> -	struct xfs_metablock	mb;
> +	struct xfs_metadump_header	xmh;
> +	struct xfs_metablock		mb;

Hmm...

> +	FILE				*src_f;
> +	char				*logdev = NULL;
> +	void				*header;
> +	int				data_dev_fd;
> +	int				log_dev_fd;
> +	int				c;
> +	bool				is_data_dev_file;
> +	bool				is_log_dev_file;
>  
>  	mdrestore.show_progress = 0;
>  	mdrestore.show_info = 0;
> @@ -327,13 +492,18 @@ main(
>  			fatal("cannot open source dump file\n");
>  	}
>  
> -	if (mdrestore_ops_v1.read_header(&mb, src_f) == 0)
> +	if (mdrestore_ops_v1.read_header(&mb, src_f) == 0) {
>  		mdrestore.mdrops = &mdrestore_ops_v1;
> -	else
> +		header = &mb;
> +	} else if (mdrestore_ops_v2.read_header(&xmh, src_f) == 0) {
> +		mdrestore.mdrops = &mdrestore_ops_v2;
> +		header = &xmh;

Perhaps define a union of both header formats, then pass that to
->read_header, ->show_info, and ->restore?

--D

> +	} else {
>  		fatal("Invalid metadump format\n");
> +	}
>  
>  	if (mdrestore.show_info) {
> -		mdrestore.mdrops->show_info(&mb, argv[optind]);
> +		mdrestore.mdrops->show_info(header, argv[optind]);
>  
>  		if (argc - optind == 1)
>  			exit(0);
> @@ -341,12 +511,21 @@ main(
>  
>  	optind++;
>  
> -	/* check and open target */
> -	dst_fd = open_device(argv[optind], &is_target_file);
> +	/* check and open data device */
> +	data_dev_fd = open_device(argv[optind], &is_data_dev_file);
> +
> +	log_dev_fd = -1;
> +	if (logdev)
> +		/* check and open log device */
> +		log_dev_fd = open_device(logdev, &is_log_dev_file);
> +
> +	mdrestore.mdrops->restore(header, src_f, data_dev_fd, is_data_dev_file,
> +				log_dev_fd, is_log_dev_file);
>  
> -	mdrestore.mdrops->restore(&mb, src_f, dst_fd, is_target_file);
> +	close(data_dev_fd);
> +	if (logdev)
> +		close(log_dev_fd);
>  
> -	close(dst_fd);
>  	if (src_f != stdin)
>  		fclose(src_f);
>  
> -- 
> 2.39.1
> 

  reply	other threads:[~2023-05-23 18:06 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-23  9:00 [PATCH 00/24] Metadump v2 Chandan Babu R
2023-05-23  9:00 ` [PATCH 01/24] metadump: Use boolean values true/false instead of 1/0 Chandan Babu R
2023-05-23 16:31   ` Darrick J. Wong
2023-05-23  9:00 ` [PATCH 02/24] mdrestore: Fix logic used to check if target device is large enough Chandan Babu R
2023-05-23 16:32   ` Darrick J. Wong
2023-05-23  9:00 ` [PATCH 03/24] metadump: Define and use struct metadump Chandan Babu R
2023-05-23 16:35   ` Darrick J. Wong
2023-05-24  4:50     ` Chandan Babu R
2023-05-23  9:00 ` [PATCH 04/24] metadump: Add initialization and release functions Chandan Babu R
2023-05-23 16:36   ` Darrick J. Wong
2023-05-24  5:03     ` Chandan Babu R
2023-05-23  9:00 ` [PATCH 05/24] set_cur: Add support to read from external log device Chandan Babu R
2023-05-23 16:48   ` Darrick J. Wong
2023-05-25  8:27     ` Chandan Babu R
2023-06-05  9:19     ` Chandan Babu R
2023-06-05 19:22       ` Darrick J. Wong
2023-06-06  4:47         ` Chandan Babu R
2023-05-23  9:00 ` [PATCH 06/24] metadump: Dump external log device contents Chandan Babu R
2023-05-23 17:02   ` Darrick J. Wong
2023-05-26  6:54     ` Chandan Babu R
2023-05-23  9:00 ` [PATCH 07/24] metadump: Postpone invocation of init_metadump() Chandan Babu R
2023-05-23 17:13   ` Darrick J. Wong
2023-05-25  8:45     ` Chandan Babu R
2023-05-23  9:00 ` [PATCH 08/24] metadump: Introduce struct metadump_ops Chandan Babu R
2023-05-23 17:15   ` Darrick J. Wong
2023-05-25  8:48     ` Chandan Babu R
2023-05-23  9:00 ` [PATCH 09/24] metadump: Introduce metadump v1 operations Chandan Babu R
2023-05-23 17:25   ` Darrick J. Wong
2023-05-25 14:19     ` Chandan Babu R
2023-06-02 14:34       ` Darrick J. Wong
2023-05-23  9:00 ` [PATCH 10/24] metadump: Rename XFS_MD_MAGIC to XFS_MD_MAGIC_V1 Chandan Babu R
2023-05-23 17:27   ` Darrick J. Wong
2023-05-23  9:00 ` [PATCH 11/24] metadump: Define metadump v2 ondisk format structures and macros Chandan Babu R
2023-05-23 17:34   ` Darrick J. Wong
2023-05-25  9:26     ` Chandan Babu R
2023-06-02 14:46       ` Darrick J. Wong
2023-05-23  9:00 ` [PATCH 12/24] metadump: Define metadump ops for v2 format Chandan Babu R
2023-05-23 17:37   ` Darrick J. Wong
2023-05-23  9:00 ` [PATCH 13/24] metadump: Add support for passing version option Chandan Babu R
2023-05-23 17:41   ` Darrick J. Wong
2023-05-23  9:00 ` [PATCH 14/24] xfs_metadump.sh: " Chandan Babu R
2023-05-23 17:39   ` Darrick J. Wong
2023-05-25  9:31     ` Chandan Babu R
2023-05-23  9:00 ` [PATCH 15/24] xfs_metadump.8: Add description for the newly introduced -v option Chandan Babu R
2023-05-23 17:40   ` Darrick J. Wong
2023-05-25 10:04     ` Chandan Babu R
2023-06-02 14:58       ` Darrick J. Wong
2023-05-23  9:00 ` [PATCH 16/24] mdrestore: Define and use struct mdrestore Chandan Babu R
2023-05-23 17:42   ` Darrick J. Wong
2023-05-26  8:38     ` Chandan Babu R
2023-05-23  9:00 ` [PATCH 17/24] mdrestore: Add open_device(), read_header() and show_info() functions Chandan Babu R
2023-05-23 17:44   ` Darrick J. Wong
2023-05-25 10:11     ` Chandan Babu R
2023-05-23  9:00 ` [PATCH 18/24] mdrestore: Introduce struct mdrestore_ops Chandan Babu R
2023-05-23 17:44   ` Darrick J. Wong
2023-05-25 10:34     ` Chandan Babu R
2023-05-23  9:00 ` [PATCH 19/24] mdrestore: Introduce mdrestore v1 operations Chandan Babu R
2023-05-23 17:48   ` Darrick J. Wong
2023-05-25 10:39     ` Chandan Babu R
2023-05-23  9:00 ` [PATCH 20/24] mdrestore: Detect metadump version from metadump image Chandan Babu R
2023-05-23 18:11   ` Darrick J. Wong
2023-05-23  9:00 ` [PATCH 21/24] mdrestore: Extract target device size verification into a function Chandan Babu R
2023-05-23 18:07   ` Darrick J. Wong
2023-05-25 12:02     ` Chandan Babu R
2023-05-23  9:00 ` [PATCH 22/24] mdrestore: Define mdrestore ops for v2 format Chandan Babu R
2023-05-23 18:06   ` Darrick J. Wong [this message]
2023-05-25 12:10     ` Chandan Babu R
2023-06-02 15:01       ` Darrick J. Wong
2023-05-23  9:00 ` [PATCH 23/24] mdrestore: Add support for passing log device as an argument Chandan Babu R
2023-05-23 18:09   ` Darrick J. Wong
2023-05-25 13:43     ` Chandan Babu R
2023-06-02 15:02       ` Darrick J. Wong
2023-06-05  6:19         ` Chandan Babu R
2023-05-23  9:00 ` [PATCH 24/24] xfs_mdrestore.8: Add description for the newly introduced -l option Chandan Babu R
2023-05-23 18:10   ` Darrick J. Wong
2023-05-25 13:45     ` Chandan Babu R

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=20230523180602.GA11620@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=cem@kernel.org \
    --cc=chandan.babu@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