public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: xfs@oss.sgi.com
Subject: [PATCH v3 03/18] libxfs: don't hardcode cycle 1 into unmount op header
Date: Fri,  2 Oct 2015 14:19:40 -0400	[thread overview]
Message-ID: <1443809995-20395-4-git-send-email-bfoster@redhat.com> (raw)
In-Reply-To: <1443809995-20395-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 | 24 +++++++++++++++++-------
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/libxfs/rdwr.c b/libxfs/rdwr.c
index bc77699..282f22d 100644
--- a/libxfs/rdwr.c
+++ b/libxfs/rdwr.c
@@ -122,7 +122,8 @@ static void unmount_record(void *p)
 	} magic = { XLOG_UNMOUNT_TYPE, 0, 0 };
 
 	memset(p, 0, BBSIZE);
-	op->oh_tid = cpu_to_be32(1);
+	/* dummy tid to mark this as written from userspace */
+	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 +189,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 +200,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 +208,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

  parent reply	other threads:[~2015-10-02 18:19 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-02 18:19 [PATCH v3 00/18] xfsprogs: format the log correctly on v5 supers Brian Foster
2015-10-02 18:19 ` [PATCH v3 01/18] libxfs: validate metadata LSNs against log on v5 superblocks Brian Foster
2015-10-02 18:19 ` [PATCH v3 02/18] libxfs: track largest metadata LSN in use via verifiers Brian Foster
2015-10-02 18:19 ` Brian Foster [this message]
2015-10-02 18:19 ` [PATCH v3 04/18] libxfs: pass lsn param to log clear and record header logging helpers Brian Foster
2015-10-02 18:19 ` [PATCH v3 05/18] libxfs: add ability to clear log to arbitrary log cycle Brian Foster
2015-10-02 18:19 ` [PATCH v3 06/18] libxlog: pull struct xlog out of xlog_is_dirty() Brian Foster
2015-10-02 18:19 ` [PATCH v3 07/18] xfs_repair: track log state throughout all recovery phases Brian Foster
2015-10-02 18:19 ` [PATCH v3 08/18] xfs_repair: process the log in no_modify mode Brian Foster
2015-10-02 18:19 ` [PATCH v3 09/18] xfs_repair: format the log with forward cycle number on v5 supers Brian Foster
2015-10-02 18:19 ` [PATCH v3 10/18] xfs_repair: don't clear the log by default Brian Foster
2015-10-02 18:19 ` [PATCH v3 11/18] xfs_repair: seed the max lsn from log state in phase 2 Brian Foster
2015-10-02 18:19 ` [PATCH v3 12/18] xfs_db: do not reset current lsn from uuid command on v5 supers Brian Foster
2015-10-02 18:19 ` [PATCH v3 13/18] db/metadump: bump lsn when log is cleared " Brian Foster
2015-10-02 18:19 ` [PATCH v3 14/18] xfs_copy: check for dirty log on non-duplicate copies Brian Foster
2015-10-02 18:19 ` [PATCH v3 15/18] xfs_copy: genericize write helper to facilitate separate log buf Brian Foster
2015-10-02 18:19 ` [PATCH v3 16/18] xfs_copy: store data buf alignment in buf data structure Brian Foster
2015-10-02 18:19 ` [PATCH v3 17/18] xfs_copy: refactor log format code into new helper Brian Foster
2015-10-02 18:19 ` [PATCH v3 18/18] xfs_copy: format v5 sb logs correctly 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=1443809995-20395-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox