2005-04-17 05:20:36 +07:00
|
|
|
/*
|
2005-11-02 10:58:39 +07:00
|
|
|
* Copyright (c) 2000-2003,2005 Silicon Graphics, Inc.
|
|
|
|
|
* All Rights Reserved.
|
2005-04-17 05:20:36 +07:00
|
|
|
*
|
2005-11-02 10:58:39 +07:00
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU General Public License as
|
2005-04-17 05:20:36 +07:00
|
|
|
* published by the Free Software Foundation.
|
|
|
|
|
*
|
2005-11-02 10:58:39 +07:00
|
|
|
* This program is distributed in the hope that it would be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
2005-04-17 05:20:36 +07:00
|
|
|
*
|
2005-11-02 10:58:39 +07:00
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with this program; if not, write the Free Software Foundation,
|
|
|
|
|
* Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
|
2005-04-17 05:20:36 +07:00
|
|
|
*/
|
|
|
|
|
#ifndef __XFS_LOG_H__
|
|
|
|
|
#define __XFS_LOG_H__
|
|
|
|
|
|
|
|
|
|
/* get lsn fields */
|
|
|
|
|
#define CYCLE_LSN(lsn) ((uint)((lsn)>>32))
|
|
|
|
|
#define BLOCK_LSN(lsn) ((uint)(lsn))
|
2007-10-12 07:59:34 +07:00
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
/* this is used in a spot where we might otherwise double-endian-flip */
|
2007-10-12 07:59:34 +07:00
|
|
|
#define CYCLE_LSN_DISK(lsn) (((__be32 *)&(lsn))[0])
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
|
#ifdef __KERNEL__
|
|
|
|
|
/*
|
2006-03-29 05:55:14 +07:00
|
|
|
* By comparing each component, we don't have to worry about extra
|
2005-04-17 05:20:36 +07:00
|
|
|
* endian issues in treating two 32 bit numbers as one 64 bit number
|
|
|
|
|
*/
|
2006-01-08 16:04:09 +07:00
|
|
|
static inline xfs_lsn_t _lsn_cmp(xfs_lsn_t lsn1, xfs_lsn_t lsn2)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
|
|
|
|
if (CYCLE_LSN(lsn1) != CYCLE_LSN(lsn2))
|
|
|
|
|
return (CYCLE_LSN(lsn1)<CYCLE_LSN(lsn2))? -999 : 999;
|
|
|
|
|
|
|
|
|
|
if (BLOCK_LSN(lsn1) != BLOCK_LSN(lsn2))
|
|
|
|
|
return (BLOCK_LSN(lsn1)<BLOCK_LSN(lsn2))? -999 : 999;
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#define XFS_LSN_CMP(x,y) _lsn_cmp(x,y)
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Macros, structures, prototypes for interface to the log manager.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Flags to xfs_log_done()
|
|
|
|
|
*/
|
|
|
|
|
#define XFS_LOG_REL_PERM_RESERV 0x1
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Flags to xfs_log_reserve()
|
|
|
|
|
*
|
|
|
|
|
* XFS_LOG_PERM_RESERV: Permanent reservation. When writes are
|
|
|
|
|
* performed against this type of reservation, the reservation
|
|
|
|
|
* is not decreased. Long running transactions should use this.
|
|
|
|
|
*/
|
|
|
|
|
#define XFS_LOG_PERM_RESERV 0x2
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Flags to xfs_log_force()
|
|
|
|
|
*
|
|
|
|
|
* XFS_LOG_SYNC: Synchronous force in-core log to disk
|
|
|
|
|
*/
|
|
|
|
|
#define XFS_LOG_SYNC 0x1
|
|
|
|
|
|
|
|
|
|
#endif /* __KERNEL__ */
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* Log Clients */
|
|
|
|
|
#define XFS_TRANSACTION 0x69
|
|
|
|
|
#define XFS_VOLUME 0x2
|
|
|
|
|
#define XFS_LOG 0xaa
|
|
|
|
|
|
2005-09-02 13:42:05 +07:00
|
|
|
|
|
|
|
|
/* Region types for iovec's i_type */
|
|
|
|
|
#define XLOG_REG_TYPE_BFORMAT 1
|
|
|
|
|
#define XLOG_REG_TYPE_BCHUNK 2
|
|
|
|
|
#define XLOG_REG_TYPE_EFI_FORMAT 3
|
|
|
|
|
#define XLOG_REG_TYPE_EFD_FORMAT 4
|
|
|
|
|
#define XLOG_REG_TYPE_IFORMAT 5
|
|
|
|
|
#define XLOG_REG_TYPE_ICORE 6
|
|
|
|
|
#define XLOG_REG_TYPE_IEXT 7
|
|
|
|
|
#define XLOG_REG_TYPE_IBROOT 8
|
|
|
|
|
#define XLOG_REG_TYPE_ILOCAL 9
|
|
|
|
|
#define XLOG_REG_TYPE_IATTR_EXT 10
|
|
|
|
|
#define XLOG_REG_TYPE_IATTR_BROOT 11
|
|
|
|
|
#define XLOG_REG_TYPE_IATTR_LOCAL 12
|
|
|
|
|
#define XLOG_REG_TYPE_QFORMAT 13
|
|
|
|
|
#define XLOG_REG_TYPE_DQUOT 14
|
|
|
|
|
#define XLOG_REG_TYPE_QUOTAOFF 15
|
|
|
|
|
#define XLOG_REG_TYPE_LRHEADER 16
|
|
|
|
|
#define XLOG_REG_TYPE_UNMOUNT 17
|
|
|
|
|
#define XLOG_REG_TYPE_COMMIT 18
|
|
|
|
|
#define XLOG_REG_TYPE_TRANSHDR 19
|
|
|
|
|
#define XLOG_REG_TYPE_MAX 19
|
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
typedef struct xfs_log_iovec {
|
2010-06-23 15:11:15 +07:00
|
|
|
void *i_addr; /* beginning address of region */
|
2005-04-17 05:20:36 +07:00
|
|
|
int i_len; /* length in bytes of region */
|
2006-01-11 17:02:47 +07:00
|
|
|
uint i_type; /* type of region */
|
2005-04-17 05:20:36 +07:00
|
|
|
} xfs_log_iovec_t;
|
|
|
|
|
|
2010-03-23 07:43:17 +07:00
|
|
|
struct xfs_log_vec {
|
|
|
|
|
struct xfs_log_vec *lv_next; /* next lv in build list */
|
|
|
|
|
int lv_niovecs; /* number of iovecs in lv */
|
|
|
|
|
struct xfs_log_iovec *lv_iovecp; /* iovec array */
|
xfs: Introduce delayed logging core code
The delayed logging code only changes in-memory structures and as
such can be enabled and disabled with a mount option. Add the mount
option and emit a warning that this is an experimental feature that
should not be used in production yet.
We also need infrastructure to track committed items that have not
yet been written to the log. This is what the Committed Item List
(CIL) is for.
The log item also needs to be extended to track the current log
vector, the associated memory buffer and it's location in the Commit
Item List. Extend the log item and log vector structures to enable
this tracking.
To maintain the current log format for transactions with delayed
logging, we need to introduce a checkpoint transaction and a context
for tracking each checkpoint from initiation to transaction
completion. This includes adding a log ticket for tracking space
log required/used by the context checkpoint.
To track all the changes we need an io vector array per log item,
rather than a single array for the entire transaction. Using the new
log vector structure for this requires two passes - the first to
allocate the log vector structures and chain them together, and the
second to fill them out. This log vector chain can then be passed
to the CIL for formatting, pinning and insertion into the CIL.
Formatting of the log vector chain is relatively simple - it's just
a loop over the iovecs on each log vector, but it is made slightly
more complex because we re-write the iovec after the copy to point
back at the memory buffer we just copied into.
This code also needs to pin log items. If the log item is not
already tracked in this checkpoint context, then it needs to be
pinned. Otherwise it is already pinned and we don't need to pin it
again.
The only other complexity is calculating the amount of new log space
the formatting has consumed. This needs to be accounted to the
transaction in progress, and the accounting is made more complex
becase we need also to steal space from it for log metadata in the
checkpoint transaction. Calculate all this at insert time and update
all the tickets, counters, etc correctly.
Once we've formatted all the log items in the transaction, attach
the busy extents to the checkpoint context so the busy extents live
until checkpoint completion and can be processed at that point in
time. Transactions can then be freed at this point in time.
Now we need to issue checkpoints - we are tracking the amount of log space
used by the items in the CIL, so we can trigger background checkpoints when the
space usage gets to a certain threshold. Otherwise, checkpoints need ot be
triggered when a log synchronisation point is reached - a log force event.
Because the log write code already handles chained log vectors, writing the
transaction is trivial, too. Construct a transaction header, add it
to the head of the chain and write it into the log, then issue a
commit record write. Then we can release the checkpoint log ticket
and attach the context to the log buffer so it can be called during
Io completion to complete the checkpoint.
We also need to allow for synchronising multiple in-flight
checkpoints. This is needed for two things - the first is to ensure
that checkpoint commit records appear in the log in the correct
sequence order (so they are replayed in the correct order). The
second is so that xfs_log_force_lsn() operates correctly and only
flushes and/or waits for the specific sequence it was provided with.
To do this we need a wait variable and a list tracking the
checkpoint commits in progress. We can walk this list and wait for
the checkpoints to change state or complete easily, an this provides
the necessary synchronisation for correct operation in both cases.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Alex Elder <aelder@sgi.com>
2010-05-21 11:37:18 +07:00
|
|
|
struct xfs_log_item *lv_item; /* owner */
|
|
|
|
|
char *lv_buf; /* formatted buffer */
|
|
|
|
|
int lv_buf_len; /* size of formatted buffer */
|
2010-03-23 07:43:17 +07:00
|
|
|
};
|
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
/*
|
|
|
|
|
* Structure used to pass callback function and the function's argument
|
|
|
|
|
* to the log manager.
|
|
|
|
|
*/
|
|
|
|
|
typedef struct xfs_log_callback {
|
|
|
|
|
struct xfs_log_callback *cb_next;
|
|
|
|
|
void (*cb_func)(void *, int);
|
|
|
|
|
void *cb_arg;
|
|
|
|
|
} xfs_log_callback_t;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#ifdef __KERNEL__
|
|
|
|
|
/* Log manager interfaces */
|
|
|
|
|
struct xfs_mount;
|
2010-02-16 06:34:54 +07:00
|
|
|
struct xlog_in_core;
|
2008-11-17 13:37:10 +07:00
|
|
|
struct xlog_ticket;
|
2010-03-23 06:10:00 +07:00
|
|
|
struct xfs_log_item;
|
|
|
|
|
struct xfs_item_ops;
|
2010-05-14 18:41:46 +07:00
|
|
|
struct xfs_trans;
|
2010-03-23 06:10:00 +07:00
|
|
|
|
|
|
|
|
void xfs_log_item_init(struct xfs_mount *mp,
|
|
|
|
|
struct xfs_log_item *item,
|
|
|
|
|
int type,
|
2011-10-28 16:54:24 +07:00
|
|
|
const struct xfs_item_ops *ops);
|
2010-02-16 06:34:54 +07:00
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
xfs_lsn_t xfs_log_done(struct xfs_mount *mp,
|
2010-02-16 06:34:54 +07:00
|
|
|
struct xlog_ticket *ticket,
|
|
|
|
|
struct xlog_in_core **iclog,
|
2005-04-17 05:20:36 +07:00
|
|
|
uint flags);
|
2005-11-02 06:26:59 +07:00
|
|
|
int _xfs_log_force(struct xfs_mount *mp,
|
|
|
|
|
uint flags,
|
|
|
|
|
int *log_forced);
|
2008-04-10 09:24:30 +07:00
|
|
|
void xfs_log_force(struct xfs_mount *mp,
|
|
|
|
|
uint flags);
|
2010-01-19 16:56:46 +07:00
|
|
|
int _xfs_log_force_lsn(struct xfs_mount *mp,
|
|
|
|
|
xfs_lsn_t lsn,
|
|
|
|
|
uint flags,
|
|
|
|
|
int *log_forced);
|
|
|
|
|
void xfs_log_force_lsn(struct xfs_mount *mp,
|
|
|
|
|
xfs_lsn_t lsn,
|
|
|
|
|
uint flags);
|
2005-04-17 05:20:36 +07:00
|
|
|
int xfs_log_mount(struct xfs_mount *mp,
|
|
|
|
|
struct xfs_buftarg *log_target,
|
|
|
|
|
xfs_daddr_t start_block,
|
|
|
|
|
int num_bblocks);
|
2008-08-13 13:49:32 +07:00
|
|
|
int xfs_log_mount_finish(struct xfs_mount *mp);
|
2005-04-17 05:20:36 +07:00
|
|
|
void xfs_log_move_tail(struct xfs_mount *mp,
|
|
|
|
|
xfs_lsn_t tail_lsn);
|
|
|
|
|
int xfs_log_notify(struct xfs_mount *mp,
|
2010-02-16 06:34:54 +07:00
|
|
|
struct xlog_in_core *iclog,
|
2005-04-17 05:20:36 +07:00
|
|
|
xfs_log_callback_t *callback_entry);
|
|
|
|
|
int xfs_log_release_iclog(struct xfs_mount *mp,
|
2010-02-16 06:34:54 +07:00
|
|
|
struct xlog_in_core *iclog);
|
2005-04-17 05:20:36 +07:00
|
|
|
int xfs_log_reserve(struct xfs_mount *mp,
|
|
|
|
|
int length,
|
|
|
|
|
int count,
|
2010-02-16 06:34:54 +07:00
|
|
|
struct xlog_ticket **ticket,
|
2005-04-17 05:20:36 +07:00
|
|
|
__uint8_t clientid,
|
2005-09-02 13:42:05 +07:00
|
|
|
uint flags,
|
|
|
|
|
uint t_type);
|
2005-04-17 05:20:36 +07:00
|
|
|
int xfs_log_unmount_write(struct xfs_mount *mp);
|
2009-03-16 14:19:29 +07:00
|
|
|
void xfs_log_unmount(struct xfs_mount *mp);
|
2005-04-17 05:20:36 +07:00
|
|
|
int xfs_log_force_umount(struct xfs_mount *mp, int logerror);
|
|
|
|
|
int xfs_log_need_covered(struct xfs_mount *mp);
|
|
|
|
|
|
|
|
|
|
void xlog_iodone(struct xfs_buf *);
|
|
|
|
|
|
xfs: Introduce delayed logging core code
The delayed logging code only changes in-memory structures and as
such can be enabled and disabled with a mount option. Add the mount
option and emit a warning that this is an experimental feature that
should not be used in production yet.
We also need infrastructure to track committed items that have not
yet been written to the log. This is what the Committed Item List
(CIL) is for.
The log item also needs to be extended to track the current log
vector, the associated memory buffer and it's location in the Commit
Item List. Extend the log item and log vector structures to enable
this tracking.
To maintain the current log format for transactions with delayed
logging, we need to introduce a checkpoint transaction and a context
for tracking each checkpoint from initiation to transaction
completion. This includes adding a log ticket for tracking space
log required/used by the context checkpoint.
To track all the changes we need an io vector array per log item,
rather than a single array for the entire transaction. Using the new
log vector structure for this requires two passes - the first to
allocate the log vector structures and chain them together, and the
second to fill them out. This log vector chain can then be passed
to the CIL for formatting, pinning and insertion into the CIL.
Formatting of the log vector chain is relatively simple - it's just
a loop over the iovecs on each log vector, but it is made slightly
more complex because we re-write the iovec after the copy to point
back at the memory buffer we just copied into.
This code also needs to pin log items. If the log item is not
already tracked in this checkpoint context, then it needs to be
pinned. Otherwise it is already pinned and we don't need to pin it
again.
The only other complexity is calculating the amount of new log space
the formatting has consumed. This needs to be accounted to the
transaction in progress, and the accounting is made more complex
becase we need also to steal space from it for log metadata in the
checkpoint transaction. Calculate all this at insert time and update
all the tickets, counters, etc correctly.
Once we've formatted all the log items in the transaction, attach
the busy extents to the checkpoint context so the busy extents live
until checkpoint completion and can be processed at that point in
time. Transactions can then be freed at this point in time.
Now we need to issue checkpoints - we are tracking the amount of log space
used by the items in the CIL, so we can trigger background checkpoints when the
space usage gets to a certain threshold. Otherwise, checkpoints need ot be
triggered when a log synchronisation point is reached - a log force event.
Because the log write code already handles chained log vectors, writing the
transaction is trivial, too. Construct a transaction header, add it
to the head of the chain and write it into the log, then issue a
commit record write. Then we can release the checkpoint log ticket
and attach the context to the log buffer so it can be called during
Io completion to complete the checkpoint.
We also need to allow for synchronising multiple in-flight
checkpoints. This is needed for two things - the first is to ensure
that checkpoint commit records appear in the log in the correct
sequence order (so they are replayed in the correct order). The
second is so that xfs_log_force_lsn() operates correctly and only
flushes and/or waits for the specific sequence it was provided with.
To do this we need a wait variable and a list tracking the
checkpoint commits in progress. We can walk this list and wait for
the checkpoints to change state or complete easily, an this provides
the necessary synchronisation for correct operation in both cases.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Alex Elder <aelder@sgi.com>
2010-05-21 11:37:18 +07:00
|
|
|
struct xlog_ticket *xfs_log_ticket_get(struct xlog_ticket *ticket);
|
2008-11-17 13:37:10 +07:00
|
|
|
void xfs_log_ticket_put(struct xlog_ticket *ticket);
|
|
|
|
|
|
2011-12-07 04:58:08 +07:00
|
|
|
int xfs_log_commit_cil(struct xfs_mount *mp, struct xfs_trans *tp,
|
xfs: Introduce delayed logging core code
The delayed logging code only changes in-memory structures and as
such can be enabled and disabled with a mount option. Add the mount
option and emit a warning that this is an experimental feature that
should not be used in production yet.
We also need infrastructure to track committed items that have not
yet been written to the log. This is what the Committed Item List
(CIL) is for.
The log item also needs to be extended to track the current log
vector, the associated memory buffer and it's location in the Commit
Item List. Extend the log item and log vector structures to enable
this tracking.
To maintain the current log format for transactions with delayed
logging, we need to introduce a checkpoint transaction and a context
for tracking each checkpoint from initiation to transaction
completion. This includes adding a log ticket for tracking space
log required/used by the context checkpoint.
To track all the changes we need an io vector array per log item,
rather than a single array for the entire transaction. Using the new
log vector structure for this requires two passes - the first to
allocate the log vector structures and chain them together, and the
second to fill them out. This log vector chain can then be passed
to the CIL for formatting, pinning and insertion into the CIL.
Formatting of the log vector chain is relatively simple - it's just
a loop over the iovecs on each log vector, but it is made slightly
more complex because we re-write the iovec after the copy to point
back at the memory buffer we just copied into.
This code also needs to pin log items. If the log item is not
already tracked in this checkpoint context, then it needs to be
pinned. Otherwise it is already pinned and we don't need to pin it
again.
The only other complexity is calculating the amount of new log space
the formatting has consumed. This needs to be accounted to the
transaction in progress, and the accounting is made more complex
becase we need also to steal space from it for log metadata in the
checkpoint transaction. Calculate all this at insert time and update
all the tickets, counters, etc correctly.
Once we've formatted all the log items in the transaction, attach
the busy extents to the checkpoint context so the busy extents live
until checkpoint completion and can be processed at that point in
time. Transactions can then be freed at this point in time.
Now we need to issue checkpoints - we are tracking the amount of log space
used by the items in the CIL, so we can trigger background checkpoints when the
space usage gets to a certain threshold. Otherwise, checkpoints need ot be
triggered when a log synchronisation point is reached - a log force event.
Because the log write code already handles chained log vectors, writing the
transaction is trivial, too. Construct a transaction header, add it
to the head of the chain and write it into the log, then issue a
commit record write. Then we can release the checkpoint log ticket
and attach the context to the log buffer so it can be called during
Io completion to complete the checkpoint.
We also need to allow for synchronising multiple in-flight
checkpoints. This is needed for two things - the first is to ensure
that checkpoint commit records appear in the log in the correct
sequence order (so they are replayed in the correct order). The
second is so that xfs_log_force_lsn() operates correctly and only
flushes and/or waits for the specific sequence it was provided with.
To do this we need a wait variable and a list tracking the
checkpoint commits in progress. We can walk this list and wait for
the checkpoints to change state or complete easily, an this provides
the necessary synchronisation for correct operation in both cases.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Alex Elder <aelder@sgi.com>
2010-05-21 11:37:18 +07:00
|
|
|
xfs_lsn_t *commit_lsn, int flags);
|
2010-05-20 20:19:42 +07:00
|
|
|
bool xfs_log_item_in_current_chkpt(struct xfs_log_item *lip);
|
xfs: Introduce delayed logging core code
The delayed logging code only changes in-memory structures and as
such can be enabled and disabled with a mount option. Add the mount
option and emit a warning that this is an experimental feature that
should not be used in production yet.
We also need infrastructure to track committed items that have not
yet been written to the log. This is what the Committed Item List
(CIL) is for.
The log item also needs to be extended to track the current log
vector, the associated memory buffer and it's location in the Commit
Item List. Extend the log item and log vector structures to enable
this tracking.
To maintain the current log format for transactions with delayed
logging, we need to introduce a checkpoint transaction and a context
for tracking each checkpoint from initiation to transaction
completion. This includes adding a log ticket for tracking space
log required/used by the context checkpoint.
To track all the changes we need an io vector array per log item,
rather than a single array for the entire transaction. Using the new
log vector structure for this requires two passes - the first to
allocate the log vector structures and chain them together, and the
second to fill them out. This log vector chain can then be passed
to the CIL for formatting, pinning and insertion into the CIL.
Formatting of the log vector chain is relatively simple - it's just
a loop over the iovecs on each log vector, but it is made slightly
more complex because we re-write the iovec after the copy to point
back at the memory buffer we just copied into.
This code also needs to pin log items. If the log item is not
already tracked in this checkpoint context, then it needs to be
pinned. Otherwise it is already pinned and we don't need to pin it
again.
The only other complexity is calculating the amount of new log space
the formatting has consumed. This needs to be accounted to the
transaction in progress, and the accounting is made more complex
becase we need also to steal space from it for log metadata in the
checkpoint transaction. Calculate all this at insert time and update
all the tickets, counters, etc correctly.
Once we've formatted all the log items in the transaction, attach
the busy extents to the checkpoint context so the busy extents live
until checkpoint completion and can be processed at that point in
time. Transactions can then be freed at this point in time.
Now we need to issue checkpoints - we are tracking the amount of log space
used by the items in the CIL, so we can trigger background checkpoints when the
space usage gets to a certain threshold. Otherwise, checkpoints need ot be
triggered when a log synchronisation point is reached - a log force event.
Because the log write code already handles chained log vectors, writing the
transaction is trivial, too. Construct a transaction header, add it
to the head of the chain and write it into the log, then issue a
commit record write. Then we can release the checkpoint log ticket
and attach the context to the log buffer so it can be called during
Io completion to complete the checkpoint.
We also need to allow for synchronising multiple in-flight
checkpoints. This is needed for two things - the first is to ensure
that checkpoint commit records appear in the log in the correct
sequence order (so they are replayed in the correct order). The
second is so that xfs_log_force_lsn() operates correctly and only
flushes and/or waits for the specific sequence it was provided with.
To do this we need a wait variable and a list tracking the
checkpoint commits in progress. We can walk this list and wait for
the checkpoints to change state or complete easily, an this provides
the necessary synchronisation for correct operation in both cases.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Alex Elder <aelder@sgi.com>
2010-05-21 11:37:18 +07:00
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
#endif
|
|
|
|
|
#endif /* __XFS_LOG_H__ */
|