From: Brian Foster <bfoster@redhat.com>
To: xfs@oss.sgi.com
Subject: [PATCH 3/9] libxfs: don't hardcode cycle 1 into unmount op header
Date: Fri, 28 Aug 2015 14:06:41 -0400 [thread overview]
Message-ID: <1440785207-17543-4-git-send-email-bfoster@redhat.com> (raw)
In-Reply-To: <1440785207-17543-1-git-send-email-bfoster@redhat.com>
The libxfs helper to write a log record after zeroing the log fills much
of the record header and unmount record with dummy data. It also
hardcodes the cycle number into the transaction oh_tid field as the
kernel expects to find the cycle stamped at the top of each block and
the original oh_tid value packed into h_cycle_data of the record header.
The log clearing code requires the ability to format the log to an
arbitrary cycle number to fix v5 superblock log recovery ordering
problems. As a result, the unmount record helper must not hardcode a
cycle of 1.
Fix up libxfs_log_header() to pack the unmount record appropriately, as
is already done for extra blocks that might exist beyond the record. Use
h_cycle_data for the original 32-bit word of the log record data block
and stamp the cycle number in its place. This allows unmount_record() to
work for arbitrary cycle numbers and libxfs_log_header() to pack a cycle
value that matches the lsn used in the record header. Note that this
patch does not change behavior as the lsn is still hardcoded to (1:0).
Signed-off-by: Brian Foster <bfoster@redhat.com>
---
libxfs/rdwr.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/libxfs/rdwr.c b/libxfs/rdwr.c
index 4f8212f..3c0179f 100644
--- a/libxfs/rdwr.c
+++ b/libxfs/rdwr.c
@@ -122,7 +122,7 @@ static void unmount_record(void *p)
} magic = { XLOG_UNMOUNT_TYPE, 0, 0 };
memset(p, 0, BBSIZE);
- op->oh_tid = cpu_to_be32(1);
+ op->oh_tid = cpu_to_be32(0xb0c0d0d0);
op->oh_len = cpu_to_be32(sizeof(magic));
op->oh_clientid = XFS_LOG;
op->oh_flags = XLOG_UNMOUNT_TRANS;
@@ -188,10 +188,6 @@ libxfs_log_header(
len = ((version == 2) && sunit) ? BTOBB(sunit) : 1;
- /* note that oh_tid actually contains the cycle number
- * and the tid is stored in h_cycle_data[0] - that's the
- * way things end up on disk.
- */
memset(p, 0, BBSIZE);
head->h_magicno = cpu_to_be32(XLOG_HEADER_MAGIC_NUM);
head->h_cycle = cpu_to_be32(1);
@@ -203,7 +199,6 @@ libxfs_log_header(
head->h_crc = cpu_to_le32(0);
head->h_prev_block = cpu_to_be32(-1);
head->h_num_logops = cpu_to_be32(1);
- head->h_cycle_data[0] = cpu_to_be32(0xb0c0d0d0);
head->h_fmt = cpu_to_be32(fmt);
head->h_size = cpu_to_be32(XLOG_HEADER_CYCLE_SIZE);
@@ -212,11 +207,25 @@ libxfs_log_header(
memcpy(&head->h_fs_uuid, fs_uuid, sizeof(uuid_t));
- len = MAX(len, 2);
p = nextfunc(p, BBSIZE, private);
unmount_record(p);
+ /*
+ * The kernel expects to see either a log record header magic or the LSN
+ * cycle at the top of every log block (for example, see
+ * xlog_[un]pack_data() and xlog_get_cycle()). Pack the unmount record
+ * block appropriately here.
+ */
cycle_lsn = CYCLE_LSN_DISK(head->h_lsn);
+ head->h_cycle_data[0] = *(__be32 *)p;
+ *(__be32 *)p = cycle_lsn;
+
+ /*
+ * Now zero any remaining blocks in the record and stamp with the cycle.
+ * Note that we don't need to swap into h_cycle_data because it has
+ * already been initialized to zero.
+ */
+ len = MAX(len, 2);
for (i = 2; i < len; i++) {
p = nextfunc(p, BBSIZE, private);
memset(p, 0, BBSIZE);
--
2.1.0
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-08-28 18:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-28 18:06 [PATCH 0/9] xfsprogs: handle the log correctly on v5 supers Brian Foster
2015-08-28 18:06 ` [PATCH 1/9] xfs: validate metadata LSNs against log on v5 superblocks Brian Foster
2015-08-28 18:06 ` [PATCH 2/9] libxfs: track largest metadata LSN in use via verifiers Brian Foster
2015-08-28 18:06 ` Brian Foster [this message]
2015-08-28 18:06 ` [PATCH 4/9] libxfs: pass lsn param to log clear and record header logging helpers Brian Foster
2015-08-28 18:06 ` [PATCH 5/9] libxfs: add ability to clear log to arbitrary log cycle Brian Foster
2015-08-28 18:06 ` [PATCH 6/9] xfs_repair: track log state throughout all recovery phases Brian Foster
2015-08-28 18:06 ` [PATCH 7/9] xfs_repair: process the log in no_modify mode Brian Foster
2015-08-28 18:06 ` [PATCH 8/9] xfs_repair: format the log with forward cycle number on v5 supers Brian Foster
2015-08-28 18:06 ` [PATCH 9/9] xfs_repair: don't clear the log by default Brian Foster
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=1440785207-17543-4-git-send-email-bfoster@redhat.com \
--to=bfoster@redhat.com \
--cc=xfs@oss.sgi.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.