From: Chandan Babu R <chandan.babu@oracle.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: cem@kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 22/24] mdrestore: Define mdrestore ops for v2 format
Date: Thu, 25 May 2023 17:40:24 +0530 [thread overview]
Message-ID: <87ilcfiib8.fsf@debian-BULLSEYE-live-builder-AMD64> (raw)
In-Reply-To: <20230523180602.GA11620@frogsfrogsfrogs>
On Tue, May 23, 2023 at 11:06:02 AM -0700, Darrick J. Wong wrote:
> 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.)
>
Thanks for pointing out the bug and suggesting the fix.
>> +
>> + 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?
>
Yes, I will add the check.
>> +
>> + 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;
> }
> }
>
I will include the above suggestion in the patchset.
>> +
>> + offset = be64_to_cpu(xme.xme_addr) & XME_ADDR_DEVICE_MASK;
>> + offset <<= BBSHIFT;
>
> offset = BBTOB(be64_to_cpu() ... ); ?
Yes, this is much better than what I had written.
>
> 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)
You probably meant to define XME_ADDR_DADDR_MASK.
> #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;
> ...
> }
Yes, this looks much better. Thanks for your suggestion.
>> +
>> + 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?
>
Yes, I agree. I will make the required changes.
>> + 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?
Sure. I will do that.
--
chandan
next prev parent reply other threads:[~2023-05-26 8:55 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
2023-05-25 12:10 ` Chandan Babu R [this message]
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=87ilcfiib8.fsf@debian-BULLSEYE-live-builder-AMD64 \
--to=chandan.babu@oracle.com \
--cc=cem@kernel.org \
--cc=djwong@kernel.org \
--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