^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) // SPDX-License-Identifier: GPL-2.0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) * Copyright (c) 2000-2003,2005 Silicon Graphics, Inc.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4) * All Rights Reserved.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) #ifndef __XFS_LOG_PRIV_H__
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) #define __XFS_LOG_PRIV_H__
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) struct xfs_buf;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) struct xlog;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) struct xlog_ticket;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) struct xfs_mount;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) * Flags for log structure
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) #define XLOG_ACTIVE_RECOVERY 0x2 /* in the middle of recovery */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) #define XLOG_RECOVERY_NEEDED 0x4 /* log was recovered */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) #define XLOG_IO_ERROR 0x8 /* log hit an I/O error, and being
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) shutdown */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) #define XLOG_TAIL_WARN 0x10 /* log tail verify warning issued */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) * get client id from packed copy.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) * this hack is here because the xlog_pack code copies four bytes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) * of xlog_op_header containing the fields oh_clientid, oh_flags
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) * and oh_res2 into the packed copy.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) * later on this four byte chunk is treated as an int and the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) * client id is pulled out.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) * this has endian issues, of course.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) static inline uint xlog_get_client_id(__be32 i)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) return be32_to_cpu(i) >> 24;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) * In core log state
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) enum xlog_iclog_state {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) XLOG_STATE_ACTIVE, /* Current IC log being written to */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) XLOG_STATE_WANT_SYNC, /* Want to sync this iclog; no more writes */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) XLOG_STATE_SYNCING, /* This IC log is syncing */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) XLOG_STATE_DONE_SYNC, /* Done syncing to disk */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) XLOG_STATE_CALLBACK, /* Callback functions now */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) XLOG_STATE_DIRTY, /* Dirty IC log, not ready for ACTIVE status */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) XLOG_STATE_IOERROR, /* IO error happened in sync'ing log */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) * Log ticket flags
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) #define XLOG_TIC_PERM_RESERV 0x1 /* permanent reservation */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) #define XLOG_TIC_FLAGS \
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) { XLOG_TIC_PERM_RESERV, "XLOG_TIC_PERM_RESERV" }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) * Below are states for covering allocation transactions.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) * By covering, we mean changing the h_tail_lsn in the last on-disk
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) * log write such that no allocation transactions will be re-done during
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) * recovery after a system crash. Recovery starts at the last on-disk
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) * log write.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) * These states are used to insert dummy log entries to cover
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) * space allocation transactions which can undo non-transactional changes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) * after a crash. Writes to a file with space
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) * already allocated do not result in any transactions. Allocations
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) * might include space beyond the EOF. So if we just push the EOF a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) * little, the last transaction for the file could contain the wrong
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) * size. If there is no file system activity, after an allocation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) * transaction, and the system crashes, the allocation transaction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) * will get replayed and the file will be truncated. This could
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) * be hours/days/... after the allocation occurred.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) * The fix for this is to do two dummy transactions when the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) * system is idle. We need two dummy transaction because the h_tail_lsn
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) * in the log record header needs to point beyond the last possible
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) * non-dummy transaction. The first dummy changes the h_tail_lsn to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) * the first transaction before the dummy. The second dummy causes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) * h_tail_lsn to point to the first dummy. Recovery starts at h_tail_lsn.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) * These dummy transactions get committed when everything
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) * is idle (after there has been some activity).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) * There are 5 states used to control this.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) * IDLE -- no logging has been done on the file system or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) * we are done covering previous transactions.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) * NEED -- logging has occurred and we need a dummy transaction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) * when the log becomes idle.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) * DONE -- we were in the NEED state and have committed a dummy
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) * transaction.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) * NEED2 -- we detected that a dummy transaction has gone to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) * on disk log with no other transactions.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) * DONE2 -- we committed a dummy transaction when in the NEED2 state.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) * There are two places where we switch states:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) * 1.) In xfs_sync, when we detect an idle log and are in NEED or NEED2.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) * We commit the dummy transaction and switch to DONE or DONE2,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) * respectively. In all other states, we don't do anything.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) * 2.) When we finish writing the on-disk log (xlog_state_clean_log).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) * No matter what state we are in, if this isn't the dummy
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) * transaction going out, the next state is NEED.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) * So, if we aren't in the DONE or DONE2 states, the next state
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) * is NEED. We can't be finishing a write of the dummy record
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) * unless it was committed and the state switched to DONE or DONE2.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) * If we are in the DONE state and this was a write of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) * dummy transaction, we move to NEED2.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) * If we are in the DONE2 state and this was a write of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) * dummy transaction, we move to IDLE.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) * Writing only one dummy transaction can get appended to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) * one file space allocation. When this happens, the log recovery
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) * code replays the space allocation and a file could be truncated.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) * This is why we have the NEED2 and DONE2 states before going idle.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) #define XLOG_STATE_COVER_IDLE 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) #define XLOG_STATE_COVER_NEED 1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) #define XLOG_STATE_COVER_DONE 2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) #define XLOG_STATE_COVER_NEED2 3
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) #define XLOG_STATE_COVER_DONE2 4
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) #define XLOG_COVER_OPS 5
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) /* Ticket reservation region accounting */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) #define XLOG_TIC_LEN_MAX 15
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) * Reservation region
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) * As would be stored in xfs_log_iovec but without the i_addr which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) * we don't care about.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) typedef struct xlog_res {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) uint r_len; /* region length :4 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) uint r_type; /* region's transaction type :4 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) } xlog_res_t;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) typedef struct xlog_ticket {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) struct list_head t_queue; /* reserve/write queue */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) struct task_struct *t_task; /* task that owns this ticket */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) xlog_tid_t t_tid; /* transaction identifier : 4 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) atomic_t t_ref; /* ticket reference count : 4 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) int t_curr_res; /* current reservation in bytes : 4 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) int t_unit_res; /* unit reservation in bytes : 4 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) char t_ocnt; /* original count : 1 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) char t_cnt; /* current count : 1 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) char t_clientid; /* who does this belong to; : 1 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) char t_flags; /* properties of reservation : 1 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) /* reservation array fields */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) uint t_res_num; /* num in array : 4 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) uint t_res_num_ophdrs; /* num op hdrs : 4 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) uint t_res_arr_sum; /* array sum : 4 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) uint t_res_o_flow; /* sum overflow : 4 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) xlog_res_t t_res_arr[XLOG_TIC_LEN_MAX]; /* array of res : 8 * 15 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) } xlog_ticket_t;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) * - A log record header is 512 bytes. There is plenty of room to grow the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) * xlog_rec_header_t into the reserved space.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) * - ic_data follows, so a write to disk can start at the beginning of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) * the iclog.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) * - ic_forcewait is used to implement synchronous forcing of the iclog to disk.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) * - ic_next is the pointer to the next iclog in the ring.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) * - ic_log is a pointer back to the global log structure.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) * - ic_size is the full size of the log buffer, minus the cycle headers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) * - ic_offset is the current number of bytes written to in this iclog.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) * - ic_refcnt is bumped when someone is writing to the log.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) * - ic_state is the state of the iclog.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) * Because of cacheline contention on large machines, we need to separate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) * various resources onto different cachelines. To start with, make the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) * structure cacheline aligned. The following fields can be contended on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) * by independent processes:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) * - ic_callbacks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) * - ic_refcnt
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) * - fields protected by the global l_icloglock
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) * so we need to ensure that these fields are located in separate cachelines.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) * We'll put all the read-only and l_icloglock fields in the first cacheline,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) * and move everything else out to subsequent cachelines.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) typedef struct xlog_in_core {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) wait_queue_head_t ic_force_wait;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) wait_queue_head_t ic_write_wait;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) struct xlog_in_core *ic_next;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) struct xlog_in_core *ic_prev;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) struct xlog *ic_log;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) u32 ic_size;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) u32 ic_offset;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) enum xlog_iclog_state ic_state;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) char *ic_datap; /* pointer to iclog data */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) /* Callback structures need their own cacheline */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) spinlock_t ic_callback_lock ____cacheline_aligned_in_smp;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) struct list_head ic_callbacks;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) /* reference counts need their own cacheline */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) atomic_t ic_refcnt ____cacheline_aligned_in_smp;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) xlog_in_core_2_t *ic_data;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) #define ic_header ic_data->hic_header
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) #ifdef DEBUG
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) bool ic_fail_crc : 1;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) #endif
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) struct semaphore ic_sema;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) struct work_struct ic_end_io_work;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) struct bio ic_bio;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) struct bio_vec ic_bvec[];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) } xlog_in_core_t;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) * The CIL context is used to aggregate per-transaction details as well be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) * passed to the iclog for checkpoint post-commit processing. After being
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) * passed to the iclog, another context needs to be allocated for tracking the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) * next set of transactions to be aggregated into a checkpoint.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) struct xfs_cil;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) struct xfs_cil_ctx {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) struct xfs_cil *cil;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) xfs_lsn_t sequence; /* chkpt sequence # */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) xfs_lsn_t start_lsn; /* first LSN of chkpt commit */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) xfs_lsn_t commit_lsn; /* chkpt commit record lsn */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) struct xlog_ticket *ticket; /* chkpt ticket */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) int nvecs; /* number of regions */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) int space_used; /* aggregate size of regions */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) struct list_head busy_extents; /* busy extents in chkpt */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) struct xfs_log_vec *lv_chain; /* logvecs being pushed */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) struct list_head iclog_entry;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) struct list_head committing; /* ctx committing list */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) struct work_struct discard_endio_work;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) * Committed Item List structure
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) * This structure is used to track log items that have been committed but not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) * yet written into the log. It is used only when the delayed logging mount
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) * option is enabled.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253) * This structure tracks the list of committing checkpoint contexts so
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254) * we can avoid the problem of having to hold out new transactions during a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) * flush until we have a the commit record LSN of the checkpoint. We can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256) * traverse the list of committing contexts in xlog_cil_push_lsn() to find a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) * sequence match and extract the commit LSN directly from there. If the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258) * checkpoint is still in the process of committing, we can block waiting for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259) * the commit LSN to be determined as well. This should make synchronous
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) * operations almost as efficient as the old logging methods.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262) struct xfs_cil {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263) struct xlog *xc_log;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264) struct list_head xc_cil;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265) spinlock_t xc_cil_lock;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) struct rw_semaphore xc_ctx_lock ____cacheline_aligned_in_smp;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268) struct xfs_cil_ctx *xc_ctx;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270) spinlock_t xc_push_lock ____cacheline_aligned_in_smp;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271) xfs_lsn_t xc_push_seq;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272) struct list_head xc_committing;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273) wait_queue_head_t xc_commit_wait;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274) xfs_lsn_t xc_current_sequence;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275) struct work_struct xc_push_work;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276) wait_queue_head_t xc_push_wait; /* background push throttle */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277) } ____cacheline_aligned_in_smp;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280) * The amount of log space we allow the CIL to aggregate is difficult to size.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281) * Whatever we choose, we have to make sure we can get a reservation for the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282) * log space effectively, that it is large enough to capture sufficient
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283) * relogging to reduce log buffer IO significantly, but it is not too large for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 284) * the log or induces too much latency when writing out through the iclogs. We
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 285) * track both space consumed and the number of vectors in the checkpoint
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 286) * context, so we need to decide which to use for limiting.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 287) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 288) * Every log buffer we write out during a push needs a header reserved, which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 289) * is at least one sector and more for v2 logs. Hence we need a reservation of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 290) * at least 512 bytes per 32k of log space just for the LR headers. That means
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 291) * 16KB of reservation per megabyte of delayed logging space we will consume,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 292) * plus various headers. The number of headers will vary based on the num of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 293) * io vectors, so limiting on a specific number of vectors is going to result
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 294) * in transactions of varying size. IOWs, it is more consistent to track and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 295) * limit space consumed in the log rather than by the number of objects being
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 296) * logged in order to prevent checkpoint ticket overruns.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 297) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 298) * Further, use of static reservations through the log grant mechanism is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 299) * problematic. It introduces a lot of complexity (e.g. reserve grant vs write
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 300) * grant) and a significant deadlock potential because regranting write space
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 301) * can block on log pushes. Hence if we have to regrant log space during a log
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 302) * push, we can deadlock.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 303) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 304) * However, we can avoid this by use of a dynamic "reservation stealing"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 305) * technique during transaction commit whereby unused reservation space in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 306) * transaction ticket is transferred to the CIL ctx commit ticket to cover the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 307) * space needed by the checkpoint transaction. This means that we never need to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 308) * specifically reserve space for the CIL checkpoint transaction, nor do we
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 309) * need to regrant space once the checkpoint completes. This also means the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 310) * checkpoint transaction ticket is specific to the checkpoint context, rather
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 311) * than the CIL itself.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 312) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 313) * With dynamic reservations, we can effectively make up arbitrary limits for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 314) * the checkpoint size so long as they don't violate any other size rules.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 315) * Recovery imposes a rule that no transaction exceed half the log, so we are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 316) * limited by that. Furthermore, the log transaction reservation subsystem
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 317) * tries to keep 25% of the log free, so we need to keep below that limit or we
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 318) * risk running out of free log space to start any new transactions.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 319) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 320) * In order to keep background CIL push efficient, we only need to ensure the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 321) * CIL is large enough to maintain sufficient in-memory relogging to avoid
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 322) * repeated physical writes of frequently modified metadata. If we allow the CIL
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 323) * to grow to a substantial fraction of the log, then we may be pinning hundreds
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 324) * of megabytes of metadata in memory until the CIL flushes. This can cause
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 325) * issues when we are running low on memory - pinned memory cannot be reclaimed,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 326) * and the CIL consumes a lot of memory. Hence we need to set an upper physical
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 327) * size limit for the CIL that limits the maximum amount of memory pinned by the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 328) * CIL but does not limit performance by reducing relogging efficiency
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 329) * significantly.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 330) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 331) * As such, the CIL push threshold ends up being the smaller of two thresholds:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 332) * - a threshold large enough that it allows CIL to be pushed and progress to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 333) * made without excessive blocking of incoming transaction commits. This is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 334) * defined to be 12.5% of the log space - half the 25% push threshold of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 335) * AIL.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 336) * - small enough that it doesn't pin excessive amounts of memory but maintains
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 337) * close to peak relogging efficiency. This is defined to be 16x the iclog
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 338) * buffer window (32MB) as measurements have shown this to be roughly the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 339) * point of diminishing performance increases under highly concurrent
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 340) * modification workloads.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 341) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 342) * To prevent the CIL from overflowing upper commit size bounds, we introduce a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 343) * new threshold at which we block committing transactions until the background
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 344) * CIL commit commences and switches to a new context. While this is not a hard
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 345) * limit, it forces the process committing a transaction to the CIL to block and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 346) * yeild the CPU, giving the CIL push work a chance to be scheduled and start
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 347) * work. This prevents a process running lots of transactions from overfilling
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 348) * the CIL because it is not yielding the CPU. We set the blocking limit at
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 349) * twice the background push space threshold so we keep in line with the AIL
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 350) * push thresholds.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 351) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 352) * Note: this is not a -hard- limit as blocking is applied after the transaction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 353) * is inserted into the CIL and the push has been triggered. It is largely a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 354) * throttling mechanism that allows the CIL push to be scheduled and run. A hard
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 355) * limit will be difficult to implement without introducing global serialisation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 356) * in the CIL commit fast path, and it's not at all clear that we actually need
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 357) * such hard limits given the ~7 years we've run without a hard limit before
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 358) * finding the first situation where a checkpoint size overflow actually
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 359) * occurred. Hence the simple throttle, and an ASSERT check to tell us that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 360) * we've overrun the max size.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 361) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 362) #define XLOG_CIL_SPACE_LIMIT(log) \
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 363) min_t(int, (log)->l_logsize >> 3, BBTOB(XLOG_TOTAL_REC_SHIFT(log)) << 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 364)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 365) #define XLOG_CIL_BLOCKING_SPACE_LIMIT(log) \
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 366) (XLOG_CIL_SPACE_LIMIT(log) * 2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 367)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 368) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 369) * ticket grant locks, queues and accounting have their own cachlines
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 370) * as these are quite hot and can be operated on concurrently.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 371) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 372) struct xlog_grant_head {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 373) spinlock_t lock ____cacheline_aligned_in_smp;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 374) struct list_head waiters;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 375) atomic64_t grant;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 376) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 377)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 378) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 379) * The reservation head lsn is not made up of a cycle number and block number.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 380) * Instead, it uses a cycle number and byte number. Logs don't expect to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 381) * overflow 31 bits worth of byte offset, so using a byte number will mean
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 382) * that round off problems won't occur when releasing partial reservations.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 383) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 384) struct xlog {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 385) /* The following fields don't need locking */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 386) struct xfs_mount *l_mp; /* mount point */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 387) struct xfs_ail *l_ailp; /* AIL log is working with */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 388) struct xfs_cil *l_cilp; /* CIL log is working with */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 389) struct xfs_buftarg *l_targ; /* buftarg of log */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 390) struct workqueue_struct *l_ioend_workqueue; /* for I/O completions */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 391) struct delayed_work l_work; /* background flush work */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 392) uint l_flags;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 393) uint l_quotaoffs_flag; /* XFS_DQ_*, for QUOTAOFFs */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 394) struct list_head *l_buf_cancel_table;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 395) int l_iclog_hsize; /* size of iclog header */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 396) int l_iclog_heads; /* # of iclog header sectors */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 397) uint l_sectBBsize; /* sector size in BBs (2^n) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 398) int l_iclog_size; /* size of log in bytes */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 399) int l_iclog_bufs; /* number of iclog buffers */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 400) xfs_daddr_t l_logBBstart; /* start block of log */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 401) int l_logsize; /* size of log in bytes */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 402) int l_logBBsize; /* size of log in BB chunks */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 403)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 404) /* The following block of fields are changed while holding icloglock */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 405) wait_queue_head_t l_flush_wait ____cacheline_aligned_in_smp;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 406) /* waiting for iclog flush */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 407) int l_covered_state;/* state of "covering disk
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 408) * log entries" */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 409) xlog_in_core_t *l_iclog; /* head log queue */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 410) spinlock_t l_icloglock; /* grab to change iclog state */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 411) int l_curr_cycle; /* Cycle number of log writes */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 412) int l_prev_cycle; /* Cycle number before last
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 413) * block increment */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 414) int l_curr_block; /* current logical log block */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 415) int l_prev_block; /* previous logical log block */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 416)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 417) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 418) * l_last_sync_lsn and l_tail_lsn are atomics so they can be set and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 419) * read without needing to hold specific locks. To avoid operations
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 420) * contending with other hot objects, place each of them on a separate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 421) * cacheline.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 422) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 423) /* lsn of last LR on disk */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 424) atomic64_t l_last_sync_lsn ____cacheline_aligned_in_smp;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 425) /* lsn of 1st LR with unflushed * buffers */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 426) atomic64_t l_tail_lsn ____cacheline_aligned_in_smp;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 427)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 428) struct xlog_grant_head l_reserve_head;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 429) struct xlog_grant_head l_write_head;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 430)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 431) struct xfs_kobj l_kobj;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 432)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 433) /* The following field are used for debugging; need to hold icloglock */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 434) #ifdef DEBUG
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 435) void *l_iclog_bak[XLOG_MAX_ICLOGS];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 436) #endif
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 437) /* log recovery lsn tracking (for buffer submission */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 438) xfs_lsn_t l_recovery_lsn;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 439) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 440)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 441) #define XLOG_BUF_CANCEL_BUCKET(log, blkno) \
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 442) ((log)->l_buf_cancel_table + ((uint64_t)blkno % XLOG_BC_TABLE_SIZE))
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 443)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 444) #define XLOG_FORCED_SHUTDOWN(log) \
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 445) (unlikely((log)->l_flags & XLOG_IO_ERROR))
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 446)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 447) /* common routines */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 448) extern int
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 449) xlog_recover(
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 450) struct xlog *log);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 451) extern int
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 452) xlog_recover_finish(
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 453) struct xlog *log);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 454) extern void
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 455) xlog_recover_cancel(struct xlog *);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 456)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 457) extern __le32 xlog_cksum(struct xlog *log, struct xlog_rec_header *rhead,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 458) char *dp, int size);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 459)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 460) extern kmem_zone_t *xfs_log_ticket_zone;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 461) struct xlog_ticket *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 462) xlog_ticket_alloc(
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 463) struct xlog *log,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 464) int unit_bytes,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 465) int count,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 466) char client,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 467) bool permanent);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 468)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 469) static inline void
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 470) xlog_write_adv_cnt(void **ptr, int *len, int *off, size_t bytes)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 471) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 472) *ptr += bytes;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 473) *len -= bytes;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 474) *off += bytes;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 475) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 476)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 477) void xlog_print_tic_res(struct xfs_mount *mp, struct xlog_ticket *ticket);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 478) void xlog_print_trans(struct xfs_trans *);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 479) int xlog_write(struct xlog *log, struct xfs_log_vec *log_vector,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 480) struct xlog_ticket *tic, xfs_lsn_t *start_lsn,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 481) struct xlog_in_core **commit_iclog, uint flags,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 482) bool need_start_rec);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 483) int xlog_commit_record(struct xlog *log, struct xlog_ticket *ticket,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 484) struct xlog_in_core **iclog, xfs_lsn_t *lsn);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 485) void xfs_log_ticket_ungrant(struct xlog *log, struct xlog_ticket *ticket);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 486) void xfs_log_ticket_regrant(struct xlog *log, struct xlog_ticket *ticket);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 487)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 488) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 489) * When we crack an atomic LSN, we sample it first so that the value will not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 490) * change while we are cracking it into the component values. This means we
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 491) * will always get consistent component values to work from. This should always
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 492) * be used to sample and crack LSNs that are stored and updated in atomic
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 493) * variables.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 494) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 495) static inline void
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 496) xlog_crack_atomic_lsn(atomic64_t *lsn, uint *cycle, uint *block)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 497) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 498) xfs_lsn_t val = atomic64_read(lsn);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 499)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 500) *cycle = CYCLE_LSN(val);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 501) *block = BLOCK_LSN(val);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 502) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 503)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 504) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 505) * Calculate and assign a value to an atomic LSN variable from component pieces.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 506) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 507) static inline void
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 508) xlog_assign_atomic_lsn(atomic64_t *lsn, uint cycle, uint block)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 509) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 510) atomic64_set(lsn, xlog_assign_lsn(cycle, block));
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 511) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 512)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 513) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 514) * When we crack the grant head, we sample it first so that the value will not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 515) * change while we are cracking it into the component values. This means we
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 516) * will always get consistent component values to work from.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 517) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 518) static inline void
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 519) xlog_crack_grant_head_val(int64_t val, int *cycle, int *space)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 520) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 521) *cycle = val >> 32;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 522) *space = val & 0xffffffff;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 523) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 524)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 525) static inline void
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 526) xlog_crack_grant_head(atomic64_t *head, int *cycle, int *space)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 527) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 528) xlog_crack_grant_head_val(atomic64_read(head), cycle, space);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 529) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 530)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 531) static inline int64_t
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 532) xlog_assign_grant_head_val(int cycle, int space)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 533) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 534) return ((int64_t)cycle << 32) | space;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 535) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 536)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 537) static inline void
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 538) xlog_assign_grant_head(atomic64_t *head, int cycle, int space)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 539) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 540) atomic64_set(head, xlog_assign_grant_head_val(cycle, space));
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 541) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 542)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 543) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 544) * Committed Item List interfaces
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 545) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 546) int xlog_cil_init(struct xlog *log);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 547) void xlog_cil_init_post_recovery(struct xlog *log);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 548) void xlog_cil_destroy(struct xlog *log);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 549) bool xlog_cil_empty(struct xlog *log);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 550)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 551) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 552) * CIL force routines
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 553) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 554) xfs_lsn_t
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 555) xlog_cil_force_lsn(
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 556) struct xlog *log,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 557) xfs_lsn_t sequence);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 558)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 559) static inline void
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 560) xlog_cil_force(struct xlog *log)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 561) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 562) xlog_cil_force_lsn(log, log->l_cilp->xc_current_sequence);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 563) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 564)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 565) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 566) * Wrapper function for waiting on a wait queue serialised against wakeups
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 567) * by a spinlock. This matches the semantics of all the wait queues used in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 568) * log code.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 569) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 570) static inline void
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 571) xlog_wait(
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 572) struct wait_queue_head *wq,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 573) struct spinlock *lock)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 574) __releases(lock)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 575) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 576) DECLARE_WAITQUEUE(wait, current);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 577)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 578) add_wait_queue_exclusive(wq, &wait);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 579) __set_current_state(TASK_UNINTERRUPTIBLE);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 580) spin_unlock(lock);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 581) schedule();
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 582) remove_wait_queue(wq, &wait);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 583) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 584)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 585) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 586) * The LSN is valid so long as it is behind the current LSN. If it isn't, this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 587) * means that the next log record that includes this metadata could have a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 588) * smaller LSN. In turn, this means that the modification in the log would not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 589) * replay.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 590) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 591) static inline bool
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 592) xlog_valid_lsn(
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 593) struct xlog *log,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 594) xfs_lsn_t lsn)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 595) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 596) int cur_cycle;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 597) int cur_block;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 598) bool valid = true;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 599)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 600) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 601) * First, sample the current lsn without locking to avoid added
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 602) * contention from metadata I/O. The current cycle and block are updated
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 603) * (in xlog_state_switch_iclogs()) and read here in a particular order
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 604) * to avoid false negatives (e.g., thinking the metadata LSN is valid
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 605) * when it is not).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 606) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 607) * The current block is always rewound before the cycle is bumped in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 608) * xlog_state_switch_iclogs() to ensure the current LSN is never seen in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 609) * a transiently forward state. Instead, we can see the LSN in a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 610) * transiently behind state if we happen to race with a cycle wrap.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 611) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 612) cur_cycle = READ_ONCE(log->l_curr_cycle);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 613) smp_rmb();
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 614) cur_block = READ_ONCE(log->l_curr_block);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 615)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 616) if ((CYCLE_LSN(lsn) > cur_cycle) ||
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 617) (CYCLE_LSN(lsn) == cur_cycle && BLOCK_LSN(lsn) > cur_block)) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 618) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 619) * If the metadata LSN appears invalid, it's possible the check
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 620) * above raced with a wrap to the next log cycle. Grab the lock
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 621) * to check for sure.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 622) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 623) spin_lock(&log->l_icloglock);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 624) cur_cycle = log->l_curr_cycle;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 625) cur_block = log->l_curr_block;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 626) spin_unlock(&log->l_icloglock);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 627)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 628) if ((CYCLE_LSN(lsn) > cur_cycle) ||
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 629) (CYCLE_LSN(lsn) == cur_cycle && BLOCK_LSN(lsn) > cur_block))
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 630) valid = false;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 631) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 632)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 633) return valid;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 634) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 635)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 636) #endif /* __XFS_LOG_PRIV_H__ */
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags