From: Brian Foster <bfoster@redhat.com>
To: xfs@oss.sgi.com
Subject: [PATCH v3 05/18] libxfs: add ability to clear log to arbitrary log cycle
Date: Fri, 2 Oct 2015 14:19:42 -0400 [thread overview]
Message-ID: <1443809995-20395-6-git-send-email-bfoster@redhat.com> (raw)
In-Reply-To: <1443809995-20395-1-git-send-email-bfoster@redhat.com>
The libxfs_log_clear() helper currently zeroes the log and writes a
single log record such that the kernel code detects the log has been
zeroed and mounts successfully. This is not sufficient for v5
filesystems, which must have the log cleared to an LSN that is
guaranteed to be ahead of any LSN that has been previously stamped into
on-disk metadata.
Update libxfs_log_clear() to support the ability to format the log to an
arbitrary cycle number. First, the log is physically zeroed. A log
record is written to the first block of the log with the desired lsn and
refers to the tail_lsn as the last record of the previous cycle. The
rest of the log is filled with log records of the previous cycle. This
causes the kernel to set the current LSN to start of the desired cycle
number at mount time.
Signed-off-by: Brian Foster <bfoster@redhat.com>
---
libxfs/rdwr.c | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 60 insertions(+), 8 deletions(-)
diff --git a/libxfs/rdwr.c b/libxfs/rdwr.c
index da781da..93f6eb7 100644
--- a/libxfs/rdwr.c
+++ b/libxfs/rdwr.c
@@ -156,26 +156,78 @@ libxfs_log_clear(
xfs_buf_t *bp;
int len;
xfs_lsn_t lsn;
+ xfs_lsn_t tail_lsn;
+ xfs_daddr_t blk;
+ xfs_daddr_t end_blk;
if (!btp->dev || !fs_uuid)
return -EINVAL;
- if (cycle != XLOG_INIT_CYCLE)
- return -EINVAL;
-
- lsn = xlog_assign_lsn(cycle, 0);
-
/* first zero the log */
libxfs_device_zero(btp, start, length);
- /* then write a log record header */
+ /*
+ * Initialize the log record length and LSNs. XLOG_INIT_CYCLE is a
+ * special reset case where we only write a single record where the lsn
+ * and tail_lsn match. Otherwise, the record lsn starts at block 0 of
+ * the specified cycle and points tail_lsn at the last record of the
+ * previous cycle.
+ */
len = ((version == 2) && sunit) ? BTOBB(sunit) : 2;
len = MAX(len, 2);
+ lsn = xlog_assign_lsn(cycle, 0);
+ if (cycle == XLOG_INIT_CYCLE)
+ tail_lsn = lsn;
+ else
+ tail_lsn = xlog_assign_lsn(cycle - 1, length - len);
+
+ /* write out the first log record */
bp = libxfs_getbufr(btp, start, len);
- libxfs_log_header(XFS_BUF_PTR(bp), fs_uuid, version, sunit, fmt, lsn,
- lsn, next, bp);
+ libxfs_log_header(XFS_BUF_PTR(bp), fs_uuid, version, sunit, fmt,
+ lsn, tail_lsn, next, bp);
bp->b_flags |= LIBXFS_B_DIRTY;
libxfs_putbufr(bp);
+
+ /*
+ * There's nothing else to do if this is a log reset. The kernel detects
+ * the rest of the log is zeroed and starts at cycle 1.
+ */
+ if (cycle == XLOG_INIT_CYCLE)
+ return 0;
+
+ /*
+ * Otherwise, fill everything beyond the initial record with records of
+ * the previous cycle so the kernel head/tail detection works correctly.
+ *
+ * We don't particularly care about the record size or content here.
+ * It's only important that the headers are in place such that the
+ * kernel finds 1.) a clean log and 2.) the correct current cycle value.
+ * Therefore, bump up the record size to the max to use larger I/Os and
+ * improve performance.
+ */
+ cycle--;
+ blk = start + len;
+ end_blk = start + length;
+
+ len = min(end_blk - blk, BTOBB(BDSTRAT_SIZE));
+ while (blk < end_blk) {
+ lsn = xlog_assign_lsn(cycle, blk - start);
+ tail_lsn = xlog_assign_lsn(cycle, blk - start - len);
+
+ bp = libxfs_getbufr(btp, blk, len);
+ /*
+ * Note: pass the full buffer length as the sunit to initialize
+ * the entire buffer.
+ */
+ libxfs_log_header(XFS_BUF_PTR(bp), fs_uuid, version, BBTOB(len),
+ fmt, lsn, tail_lsn, next, bp);
+ bp->b_flags |= LIBXFS_B_DIRTY;
+ libxfs_putbufr(bp);
+
+ len = min(end_blk - blk, BTOBB(BDSTRAT_SIZE));
+ blk += len;
+ }
+
return 0;
}
--
2.1.0
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-10-02 18:20 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 ` [PATCH v3 03/18] libxfs: don't hardcode cycle 1 into unmount op header Brian Foster
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 ` Brian Foster [this message]
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-6-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