2018-06-06 05:42:14 +03:00
// SPDX-License-Identifier: GPL-2.0
2005-04-17 02:20:36 +04:00
/*
2005-11-02 06:58:39 +03:00
* Copyright ( c ) 2000 - 2005 Silicon Graphics , Inc .
* All Rights Reserved .
2005-04-17 02:20:36 +04:00
*/
# include "xfs.h"
2005-11-02 06:38:42 +03:00
# include "xfs_fs.h"
2019-06-29 05:25:35 +03:00
# include "xfs_shared.h"
2014-11-28 06:25:04 +03:00
# include "xfs_format.h"
2013-10-23 03:50:10 +04:00
# include "xfs_log_format.h"
# include "xfs_trans_resv.h"
2005-11-02 06:38:42 +03:00
# include "xfs_bit.h"
2005-04-17 02:20:36 +04:00
# include "xfs_mount.h"
2013-10-23 03:50:10 +04:00
# include "xfs_trans.h"
2005-11-02 06:38:42 +03:00
# include "xfs_buf_item.h"
2005-04-17 02:20:36 +04:00
# include "xfs_trans_priv.h"
2009-12-15 02:14:59 +03:00
# include "xfs_trace.h"
2013-10-23 03:50:10 +04:00
# include "xfs_log.h"
2005-04-17 02:20:36 +04:00
kmem_zone_t * xfs_buf_item_zone ;
2010-06-23 12:11:15 +04:00
static inline struct xfs_buf_log_item * BUF_ITEM ( struct xfs_log_item * lip )
{
return container_of ( lip , struct xfs_buf_log_item , bli_item ) ;
}
2010-12-03 09:00:52 +03:00
STATIC void xfs_buf_do_callbacks ( struct xfs_buf * bp ) ;
2005-04-17 02:20:36 +04:00
2020-01-14 03:33:46 +03:00
/* Is this log iovec plausibly large enough to contain the buffer log format? */
bool
xfs_buf_log_check_iovec (
struct xfs_log_iovec * iovec )
{
struct xfs_buf_log_format * blfp = iovec - > i_addr ;
char * bmp_end ;
char * item_end ;
if ( offsetof ( struct xfs_buf_log_format , blf_data_map ) > iovec - > i_len )
return false ;
item_end = ( char * ) iovec - > i_addr + iovec - > i_len ;
bmp_end = ( char * ) & blfp - > blf_data_map [ blfp - > blf_map_size ] ;
return bmp_end < = item_end ;
}
2013-08-12 14:50:04 +04:00
static inline int
xfs_buf_log_format_size (
struct xfs_buf_log_format * blfp )
{
return offsetof ( struct xfs_buf_log_format , blf_data_map ) +
( blfp - > blf_map_size * sizeof ( blfp - > blf_data_map [ 0 ] ) ) ;
}
2005-04-17 02:20:36 +04:00
/*
* This returns the number of log iovecs needed to log the
* given buf log item .
*
* It calculates this as 1 iovec for the buf log format structure
* and 1 for each stretch of non - contiguous chunks to be logged .
* Contiguous chunks are logged in a single iovec .
*
* If the XFS_BLI_STALE flag has been set , then log nothing .
*/
2013-08-12 14:50:04 +04:00
STATIC void
2012-06-22 12:50:12 +04:00
xfs_buf_item_size_segment (
2018-01-25 00:38:48 +03:00
struct xfs_buf_log_item * bip ,
struct xfs_buf_log_format * blfp ,
int * nvecs ,
int * nbytes )
2005-04-17 02:20:36 +04:00
{
2018-01-25 00:38:48 +03:00
struct xfs_buf * bp = bip - > bli_buf ;
int next_bit ;
int last_bit ;
2005-04-17 02:20:36 +04:00
2012-06-22 12:50:12 +04:00
last_bit = xfs_next_bit ( blfp - > blf_data_map , blfp - > blf_map_size , 0 ) ;
if ( last_bit = = - 1 )
2013-08-12 14:50:04 +04:00
return ;
2012-06-22 12:50:12 +04:00
/*
* initial count for a dirty buffer is 2 vectors - the format structure
* and the first dirty region .
*/
2013-08-12 14:50:04 +04:00
* nvecs + = 2 ;
* nbytes + = xfs_buf_log_format_size ( blfp ) + XFS_BLF_CHUNK ;
2005-04-17 02:20:36 +04:00
while ( last_bit ! = - 1 ) {
/*
* This takes the bit number to start looking from and
* returns the next set bit from there . It returns - 1
* if there are no more bits set or the start bit is
* beyond the end of the bitmap .
*/
2012-06-22 12:50:12 +04:00
next_bit = xfs_next_bit ( blfp - > blf_data_map , blfp - > blf_map_size ,
last_bit + 1 ) ;
2005-04-17 02:20:36 +04:00
/*
* If we run out of bits , leave the loop ,
* else if we find a new set of bits bump the number of vecs ,
* else keep scanning the current set of bits .
*/
if ( next_bit = = - 1 ) {
2012-06-22 12:50:12 +04:00
break ;
2005-04-17 02:20:36 +04:00
} else if ( next_bit ! = last_bit + 1 ) {
last_bit = next_bit ;
2013-08-12 14:50:04 +04:00
( * nvecs ) + + ;
2010-05-07 05:05:19 +04:00
} else if ( xfs_buf_offset ( bp , next_bit * XFS_BLF_CHUNK ) ! =
( xfs_buf_offset ( bp , last_bit * XFS_BLF_CHUNK ) +
XFS_BLF_CHUNK ) ) {
2005-04-17 02:20:36 +04:00
last_bit = next_bit ;
2013-08-12 14:50:04 +04:00
( * nvecs ) + + ;
2005-04-17 02:20:36 +04:00
} else {
last_bit + + ;
}
2013-08-12 14:50:04 +04:00
* nbytes + = XFS_BLF_CHUNK ;
2005-04-17 02:20:36 +04:00
}
}
/*
2012-06-22 12:50:12 +04:00
* This returns the number of log iovecs needed to log the given buf log item .
*
* It calculates this as 1 iovec for the buf log format structure and 1 for each
* stretch of non - contiguous chunks to be logged . Contiguous chunks are logged
* in a single iovec .
*
* Discontiguous buffers need a format structure per region that that is being
* logged . This makes the changes in the buffer appear to log recovery as though
* they came from separate buffers , just like would occur if multiple buffers
* were used instead of a single discontiguous buffer . This enables
* discontiguous buffers to be in - memory constructs , completely transparent to
* what ends up on disk .
*
* If the XFS_BLI_STALE flag has been set , then log nothing but the buf log
* format structures .
2005-04-17 02:20:36 +04:00
*/
2013-08-12 14:50:04 +04:00
STATIC void
2012-06-22 12:50:12 +04:00
xfs_buf_item_size (
2013-08-12 14:50:04 +04:00
struct xfs_log_item * lip ,
int * nvecs ,
int * nbytes )
2005-04-17 02:20:36 +04:00
{
2010-06-23 12:11:15 +04:00
struct xfs_buf_log_item * bip = BUF_ITEM ( lip ) ;
2012-06-22 12:50:12 +04:00
int i ;
ASSERT ( atomic_read ( & bip - > bli_refcount ) > 0 ) ;
if ( bip - > bli_flags & XFS_BLI_STALE ) {
/*
* The buffer is stale , so all we need to log
* is the buf log format structure with the
* cancel flag in it .
*/
trace_xfs_buf_item_size_stale ( bip ) ;
2012-12-05 03:18:03 +04:00
ASSERT ( bip - > __bli_format . blf_flags & XFS_BLF_CANCEL ) ;
2013-08-12 14:50:04 +04:00
* nvecs + = bip - > bli_format_count ;
for ( i = 0 ; i < bip - > bli_format_count ; i + + ) {
* nbytes + = xfs_buf_log_format_size ( & bip - > bli_formats [ i ] ) ;
}
return ;
2012-06-22 12:50:12 +04:00
}
ASSERT ( bip - > bli_flags & XFS_BLI_LOGGED ) ;
2013-06-27 10:04:52 +04:00
if ( bip - > bli_flags & XFS_BLI_ORDERED ) {
/*
* The buffer has been logged just to order it .
* It is not being included in the transaction
* commit , so no vectors are used at all .
*/
trace_xfs_buf_item_size_ordered ( bip ) ;
2013-08-12 14:50:04 +04:00
* nvecs = XFS_LOG_VEC_ORDERED ;
return ;
2013-06-27 10:04:52 +04:00
}
2012-06-22 12:50:12 +04:00
/*
* the vector count is based on the number of buffer vectors we have
* dirty bits in . This will only be greater than one when we have a
* compound buffer with more than one segment dirty . Hence for compound
* buffers we need to track which segment the dirty bits correspond to ,
* and when we move from one segment to the next increment the vector
* count for the extra buf log format structure that will need to be
* written .
*/
for ( i = 0 ; i < bip - > bli_format_count ; i + + ) {
2013-08-12 14:50:04 +04:00
xfs_buf_item_size_segment ( bip , & bip - > bli_formats [ i ] ,
nvecs , nbytes ) ;
2012-06-22 12:50:12 +04:00
}
trace_xfs_buf_item_size ( bip ) ;
}
2013-12-13 04:00:43 +04:00
static inline void
2013-12-13 04:00:43 +04:00
xfs_buf_item_copy_iovec (
2013-12-13 04:34:02 +04:00
struct xfs_log_vec * lv ,
2013-12-13 04:00:43 +04:00
struct xfs_log_iovec * * vecp ,
2013-12-13 04:00:43 +04:00
struct xfs_buf * bp ,
uint offset ,
int first_bit ,
uint nbits )
{
offset + = first_bit * XFS_BLF_CHUNK ;
2013-12-13 04:34:02 +04:00
xlog_copy_iovec ( lv , vecp , XLOG_REG_TYPE_BCHUNK ,
2013-12-13 04:00:43 +04:00
xfs_buf_offset ( bp , offset ) ,
nbits * XFS_BLF_CHUNK ) ;
2013-12-13 04:00:43 +04:00
}
static inline bool
xfs_buf_item_straddle (
struct xfs_buf * bp ,
uint offset ,
int next_bit ,
int last_bit )
{
return xfs_buf_offset ( bp , offset + ( next_bit < < XFS_BLF_SHIFT ) ) ! =
( xfs_buf_offset ( bp , offset + ( last_bit < < XFS_BLF_SHIFT ) ) +
XFS_BLF_CHUNK ) ;
}
2013-12-13 04:00:43 +04:00
static void
2012-06-22 12:50:12 +04:00
xfs_buf_item_format_segment (
struct xfs_buf_log_item * bip ,
2013-12-13 04:34:02 +04:00
struct xfs_log_vec * lv ,
2013-12-13 04:00:43 +04:00
struct xfs_log_iovec * * vecp ,
2012-06-22 12:50:12 +04:00
uint offset ,
struct xfs_buf_log_format * blfp )
{
2018-01-25 00:38:48 +03:00
struct xfs_buf * bp = bip - > bli_buf ;
uint base_size ;
int first_bit ;
int last_bit ;
int next_bit ;
uint nbits ;
2005-04-17 02:20:36 +04:00
2012-06-22 12:50:12 +04:00
/* copy the flags across from the base format item */
2012-12-05 03:18:03 +04:00
blfp - > blf_flags = bip - > __bli_format . blf_flags ;
2005-04-17 02:20:36 +04:00
/*
2012-06-22 12:50:07 +04:00
* Base size is the actual size of the ondisk structure - it reflects
* the actual size of the dirty bitmap rather than the size of the in
* memory structure .
2005-04-17 02:20:36 +04:00
*/
2013-08-12 14:50:04 +04:00
base_size = xfs_buf_log_format_size ( blfp ) ;
2012-12-05 03:18:04 +04:00
first_bit = xfs_next_bit ( blfp - > blf_data_map , blfp - > blf_map_size , 0 ) ;
if ( ! ( bip - > bli_flags & XFS_BLI_STALE ) & & first_bit = = - 1 ) {
/*
* If the map is not be dirty in the transaction , mark
* the size as zero and do not advance the vector pointer .
*/
2013-12-13 04:34:02 +04:00
return ;
2012-12-05 03:18:04 +04:00
}
2013-12-13 04:34:02 +04:00
blfp = xlog_copy_iovec ( lv , vecp , XLOG_REG_TYPE_BFORMAT , blfp , base_size ) ;
blfp - > blf_size = 1 ;
2005-04-17 02:20:36 +04:00
if ( bip - > bli_flags & XFS_BLI_STALE ) {
/*
* The buffer is stale , so all we need to log
* is the buf log format structure with the
* cancel flag in it .
*/
2009-12-15 02:14:59 +03:00
trace_xfs_buf_item_format_stale ( bip ) ;
2012-06-22 12:50:12 +04:00
ASSERT ( blfp - > blf_flags & XFS_BLF_CANCEL ) ;
2013-12-13 04:34:02 +04:00
return ;
2005-04-17 02:20:36 +04:00
}
2013-06-27 10:04:52 +04:00
2005-04-17 02:20:36 +04:00
/*
* Fill in an iovec for each set of contiguous chunks .
*/
last_bit = first_bit ;
nbits = 1 ;
for ( ; ; ) {
/*
* This takes the bit number to start looking from and
* returns the next set bit from there . It returns - 1
* if there are no more bits set or the start bit is
* beyond the end of the bitmap .
*/
2012-06-22 12:50:12 +04:00
next_bit = xfs_next_bit ( blfp - > blf_data_map , blfp - > blf_map_size ,
( uint ) last_bit + 1 ) ;
2005-04-17 02:20:36 +04:00
/*
2013-12-13 04:00:43 +04:00
* If we run out of bits fill in the last iovec and get out of
* the loop . Else if we start a new set of bits then fill in
* the iovec for the series we were looking at and start
* counting the bits in the new one . Else we ' re still in the
* same set of bits so just keep counting and scanning .
2005-04-17 02:20:36 +04:00
*/
if ( next_bit = = - 1 ) {
2013-12-13 04:34:02 +04:00
xfs_buf_item_copy_iovec ( lv , vecp , bp , offset ,
2013-12-13 04:00:43 +04:00
first_bit , nbits ) ;
2013-12-13 04:34:02 +04:00
blfp - > blf_size + + ;
2005-04-17 02:20:36 +04:00
break ;
2013-12-13 04:00:43 +04:00
} else if ( next_bit ! = last_bit + 1 | |
xfs_buf_item_straddle ( bp , offset , next_bit , last_bit ) ) {
2013-12-13 04:34:02 +04:00
xfs_buf_item_copy_iovec ( lv , vecp , bp , offset ,
2013-12-13 04:00:43 +04:00
first_bit , nbits ) ;
2013-12-13 04:34:02 +04:00
blfp - > blf_size + + ;
2005-04-17 02:20:36 +04:00
first_bit = next_bit ;
last_bit = next_bit ;
nbits = 1 ;
} else {
last_bit + + ;
nbits + + ;
}
}
2012-06-22 12:50:12 +04:00
}
/*
* This is called to fill in the vector of log iovecs for the
* given log buf item . It fills the first entry with a buf log
* format structure , and the rest point to contiguous chunks
* within the buffer .
*/
STATIC void
xfs_buf_item_format (
struct xfs_log_item * lip ,
2013-12-13 04:34:02 +04:00
struct xfs_log_vec * lv )
2012-06-22 12:50:12 +04:00
{
struct xfs_buf_log_item * bip = BUF_ITEM ( lip ) ;
struct xfs_buf * bp = bip - > bli_buf ;
2013-12-13 04:34:02 +04:00
struct xfs_log_iovec * vecp = NULL ;
2012-06-22 12:50:12 +04:00
uint offset = 0 ;
int i ;
ASSERT ( atomic_read ( & bip - > bli_refcount ) > 0 ) ;
ASSERT ( ( bip - > bli_flags & XFS_BLI_LOGGED ) | |
( bip - > bli_flags & XFS_BLI_STALE ) ) ;
2015-01-22 01:29:05 +03:00
ASSERT ( ( bip - > bli_flags & XFS_BLI_STALE ) | |
( xfs_blft_from_flags ( & bip - > __bli_format ) > XFS_BLFT_UNKNOWN_BUF
& & xfs_blft_from_flags ( & bip - > __bli_format ) < XFS_BLFT_MAX_BUF ) ) ;
2017-08-29 20:08:37 +03:00
ASSERT ( ! ( bip - > bli_flags & XFS_BLI_ORDERED ) | |
( bip - > bli_flags & XFS_BLI_STALE ) ) ;
2015-01-22 01:29:05 +03:00
2012-06-22 12:50:12 +04:00
/*
* If it is an inode buffer , transfer the in - memory state to the
2013-06-27 10:04:56 +04:00
* format flags and clear the in - memory state .
*
* For buffer based inode allocation , we do not transfer
2012-06-22 12:50:12 +04:00
* this state if the inode buffer allocation has not yet been committed
* to the log as setting the XFS_BLI_INODE_BUF flag will prevent
* correct replay of the inode allocation .
2013-06-27 10:04:56 +04:00
*
* For icreate item based inode allocation , the buffers aren ' t written
* to the journal during allocation , and hence we should always tag the
* buffer as an inode buffer so that the correct unlinked list replay
* occurs during recovery .
2012-06-22 12:50:12 +04:00
*/
if ( bip - > bli_flags & XFS_BLI_INODE_BUF ) {
2013-06-27 10:04:56 +04:00
if ( xfs_sb_version_hascrc ( & lip - > li_mountp - > m_sb ) | |
! ( ( bip - > bli_flags & XFS_BLI_INODE_ALLOC_BUF ) & &
2012-06-22 12:50:12 +04:00
xfs_log_item_in_current_chkpt ( lip ) ) )
2012-12-05 03:18:03 +04:00
bip - > __bli_format . blf_flags | = XFS_BLF_INODE_BUF ;
2012-06-22 12:50:12 +04:00
bip - > bli_flags & = ~ XFS_BLI_INODE_BUF ;
}
for ( i = 0 ; i < bip - > bli_format_count ; i + + ) {
2013-12-13 04:34:02 +04:00
xfs_buf_item_format_segment ( bip , lv , & vecp , offset ,
2013-12-13 04:00:43 +04:00
& bip - > bli_formats [ i ] ) ;
xfs: fix broken multi-fsb buffer logging
Multi-block buffers are logged based on buffer offset in
xfs_trans_log_buf(). xfs_buf_item_log() ultimately walks each mapping in
the buffer and marks the associated range to be logged in the
xfs_buf_log_format bitmap for that mapping. This code is broken,
however, in that it marks the actual buffer offsets of the associated
range in each bitmap rather than shifting to the byte range for that
particular mapping.
For example, on a 4k fsb fs, buffer offset 4096 refers to the first byte
of the second mapping in the buffer. This means byte 0 of the second log
format bitmap should be tagged as dirty. Instead, the current code marks
byte offset 4096 of the second log format bitmap, which is invalid and
potentially out of range of the mapping.
As a result of this, the log item format code invoked at transaction
commit time is not be able to correctly identify what parts of the
buffer to copy into log vectors. This can lead to NULL log vector
pointer dereferences in CIL push context if the item format code was not
able to locate any dirty ranges at all. This crash has been reproduced
on a 4k FSB filesystem using 16k directory blocks where an unlink
operation happened not to log anything in the first block of the
mapping. The logged offsets were all over 4k, marked as such in the
subsequent log format mappings, and thus left the transaction with an
xfs_log_item that is marked DIRTY but without any logged regions.
Further, even when the logged regions are marked correctly in the buffer
log format bitmaps, the format code doesn't copy the correct ranges of
the buffer into the log. This means that any logged region beyond the
first block of a multi-block buffer is subject to corruption after a
crash and log recovery sequence. This is due to a failure to convert the
mapping bm_len field from basic blocks to bytes in the buffer offset
tracking code in xfs_buf_item_format().
Update xfs_buf_item_log() to convert buffer offsets to segment relative
offsets when logging multi-block buffers. This ensures that the modified
regions of a buffer are logged correctly and avoids the aforementioned
crash. Also update xfs_buf_item_format() to correctly track the source
offset into the buffer for the log vector formatting code. This ensures
that the correct data is copied into the log.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-06-01 10:38:12 +03:00
offset + = BBTOB ( bp - > b_maps [ i ] . bm_len ) ;
2012-06-22 12:50:12 +04:00
}
2005-04-17 02:20:36 +04:00
/*
* Check to make sure everything is consistent .
*/
2009-12-15 02:14:59 +03:00
trace_xfs_buf_item_format ( bip ) ;
2005-04-17 02:20:36 +04:00
}
/*
2010-05-07 05:04:34 +04:00
* This is called to pin the buffer associated with the buf log item in memory
2010-06-23 12:11:15 +04:00
* so it cannot be written out .
2010-05-07 05:04:34 +04:00
*
* We also always take a reference to the buffer log item here so that the bli
* is held while the item is pinned in memory . This means that we can
* unconditionally drop the reference count a transaction holds when the
* transaction is completed .
2005-04-17 02:20:36 +04:00
*/
2005-06-21 09:36:52 +04:00
STATIC void
2005-04-17 02:20:36 +04:00
xfs_buf_item_pin (
2010-06-23 12:11:15 +04:00
struct xfs_log_item * lip )
2005-04-17 02:20:36 +04:00
{
2010-06-23 12:11:15 +04:00
struct xfs_buf_log_item * bip = BUF_ITEM ( lip ) ;
2005-04-17 02:20:36 +04:00
ASSERT ( atomic_read ( & bip - > bli_refcount ) > 0 ) ;
ASSERT ( ( bip - > bli_flags & XFS_BLI_LOGGED ) | |
2013-06-27 10:04:52 +04:00
( bip - > bli_flags & XFS_BLI_ORDERED ) | |
2005-04-17 02:20:36 +04:00
( bip - > bli_flags & XFS_BLI_STALE ) ) ;
2010-06-23 12:11:15 +04:00
2009-12-15 02:14:59 +03:00
trace_xfs_buf_item_pin ( bip ) ;
2010-06-23 12:11:15 +04:00
atomic_inc ( & bip - > bli_refcount ) ;
atomic_inc ( & bip - > bli_buf - > b_pin_count ) ;
2005-04-17 02:20:36 +04:00
}
/*
* This is called to unpin the buffer associated with the buf log
* item which was previously pinned with a call to xfs_buf_item_pin ( ) .
*
* Also drop the reference to the buf item for the current transaction .
* If the XFS_BLI_STALE flag is set and we are the last reference ,
* then free up the buf log item and unlock the buffer .
2010-06-23 12:11:15 +04:00
*
* If the remove flag is set we are called from uncommit in the
* forced - shutdown path . If that is true and the reference count on
* the log item is going to drop to zero we need to free the item ' s
* descriptor in the transaction .
2005-04-17 02:20:36 +04:00
*/
2005-06-21 09:36:52 +04:00
STATIC void
2005-04-17 02:20:36 +04:00
xfs_buf_item_unpin (
2010-06-23 12:11:15 +04:00
struct xfs_log_item * lip ,
2010-06-23 12:11:15 +04:00
int remove )
2005-04-17 02:20:36 +04:00
{
2010-06-23 12:11:15 +04:00
struct xfs_buf_log_item * bip = BUF_ITEM ( lip ) ;
2018-01-25 00:38:48 +03:00
xfs_buf_t * bp = bip - > bli_buf ;
struct xfs_ail * ailp = lip - > li_ailp ;
int stale = bip - > bli_flags & XFS_BLI_STALE ;
int freed ;
2005-04-17 02:20:36 +04:00
2018-01-25 00:38:48 +03:00
ASSERT ( bp - > b_log_item = = bip ) ;
2005-04-17 02:20:36 +04:00
ASSERT ( atomic_read ( & bip - > bli_refcount ) > 0 ) ;
2010-06-23 12:11:15 +04:00
2009-12-15 02:14:59 +03:00
trace_xfs_buf_item_unpin ( bip ) ;
2005-04-17 02:20:36 +04:00
freed = atomic_dec_and_test ( & bip - > bli_refcount ) ;
2010-06-23 12:11:15 +04:00
if ( atomic_dec_and_test ( & bp - > b_pin_count ) )
wake_up_all ( & bp - > b_waiters ) ;
2010-06-23 12:11:15 +04:00
2005-04-17 02:20:36 +04:00
if ( freed & & stale ) {
ASSERT ( bip - > bli_flags & XFS_BLI_STALE ) ;
2011-07-08 16:36:19 +04:00
ASSERT ( xfs_buf_islocked ( bp ) ) ;
2016-02-10 07:01:11 +03:00
ASSERT ( bp - > b_flags & XBF_STALE ) ;
2012-12-05 03:18:03 +04:00
ASSERT ( bip - > __bli_format . blf_flags & XFS_BLF_CANCEL ) ;
2010-06-23 12:11:15 +04:00
2009-12-15 02:14:59 +03:00
trace_xfs_buf_item_unpin_stale ( bip ) ;
2010-06-23 12:11:15 +04:00
if ( remove ) {
/*
2011-01-27 04:13:35 +03:00
* If we are in a transaction context , we have to
* remove the log item from the transaction as we are
* about to release our reference to the buffer . If we
* don ' t , the unlock that occurs later in
* xfs_trans_uncommit ( ) will try to reference the
2010-06-23 12:11:15 +04:00
* buffer which we no longer have a hold on .
*/
2018-05-09 17:49:37 +03:00
if ( ! list_empty ( & lip - > li_trans ) )
2011-01-27 04:13:35 +03:00
xfs_trans_del_item ( lip ) ;
2010-06-23 12:11:15 +04:00
/*
* Since the transaction no longer refers to the buffer ,
* the buffer should no longer refer to the transaction .
*/
2011-07-13 15:43:49 +04:00
bp - > b_transp = NULL ;
2010-06-23 12:11:15 +04:00
}
2005-04-17 02:20:36 +04:00
/*
* If we get called here because of an IO error , we may
2008-10-30 09:39:58 +03:00
* or may not have the item on the AIL . xfs_trans_ail_delete ( )
2005-04-17 02:20:36 +04:00
* will take care of that situation .
2008-10-30 09:39:58 +03:00
* xfs_trans_ail_delete ( ) drops the AIL lock .
2005-04-17 02:20:36 +04:00
*/
if ( bip - > bli_flags & XFS_BLI_STALE_INODE ) {
2010-12-03 09:00:52 +03:00
xfs_buf_do_callbacks ( bp ) ;
2018-01-25 00:38:48 +03:00
bp - > b_log_item = NULL ;
2018-01-25 00:38:49 +03:00
list_del_init ( & bp - > b_li_list ) ;
2011-07-13 15:43:49 +04:00
bp - > b_iodone = NULL ;
2005-04-17 02:20:36 +04:00
} else {
2018-03-08 01:59:39 +03:00
spin_lock ( & ailp - > ail_lock ) ;
2012-04-23 09:58:41 +04:00
xfs_trans_ail_delete ( ailp , lip , SHUTDOWN_LOG_IO_ERROR ) ;
2005-04-17 02:20:36 +04:00
xfs_buf_item_relse ( bp ) ;
2018-01-25 00:38:48 +03:00
ASSERT ( bp - > b_log_item = = NULL ) ;
2005-04-17 02:20:36 +04:00
}
xfs_buf_relse ( bp ) ;
2012-04-23 09:58:38 +04:00
} else if ( freed & & remove ) {
2012-11-02 07:23:12 +04:00
/*
* There are currently two references to the buffer - the active
* LRU reference and the buf log item . What we are about to do
* here - simulate a failed IO completion - requires 3
* references .
*
* The LRU reference is removed by the xfs_buf_stale ( ) call . The
* buf item reference is removed by the xfs_buf_iodone ( )
* callback that is run by xfs_buf_do_callbacks ( ) during ioend
* processing ( via the bp - > b_iodone callback ) , and then finally
* the ioend processing will drop the IO reference if the buffer
* is marked XBF_ASYNC .
*
* Hence we need to take an additional reference here so that IO
* completion processing doesn ' t free the buffer prematurely .
*/
2012-04-23 09:58:38 +04:00
xfs_buf_lock ( bp ) ;
2012-11-02 07:23:12 +04:00
xfs_buf_hold ( bp ) ;
bp - > b_flags | = XBF_ASYNC ;
2014-06-25 08:58:08 +04:00
xfs_buf_ioerror ( bp , - EIO ) ;
2016-02-10 07:01:11 +03:00
bp - > b_flags & = ~ XBF_DONE ;
2012-04-23 09:58:38 +04:00
xfs_buf_stale ( bp ) ;
2014-10-02 03:04:22 +04:00
xfs_buf_ioend ( bp ) ;
2005-04-17 02:20:36 +04:00
}
}
xfs: abort metadata writeback on permanent errors
If we are doing aysnc writeback of metadata, we can get write errors
but have nobody to report them to. At the moment, we simply attempt
to reissue the write from io completion in the hope that it's a
transient error.
When it's not a transient error, the buffer is stuck forever in
this loop, and we cannot break out of it. Eventually, unmount will
hang because the AIL cannot be emptied and everything goes downhill
from them.
To solve this problem, only retry the write IO once before aborting
it. We don't throw the buffer away because some transient errors can
last minutes (e.g. FC path failover) or even hours (thin
provisioned devices that have run out of backing space) before they
go away. Hence we really want to keep trying until we can't try any
more.
Because the buffer was not cleaned, however, it does not get removed
from the AIL and hence the next pass across the AIL will start IO on
it again. As such, we still get the "retry forever" semantics that
we currently have, but we allow other access to the buffer in the
mean time. Meanwhile the filesystem can continue to modify the
buffer and relog it, so the IO errors won't hang the log or the
filesystem.
Now when we are pushing the AIL, we can see all these "permanent IO
error" buffers and we can issue a warning about failures before we
retry the IO. We can also catch these buffers when unmounting an
issue a corruption warning, too.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ben Myers <bpm@sgi.com>
2013-12-12 09:34:38 +04:00
/*
* Buffer IO error rate limiting . Limit it to no more than 10 messages per 30
* seconds so as to not spam logs too much on repeated detection of the same
* buffer being bad . .
*/
2014-09-23 10:15:45 +04:00
static DEFINE_RATELIMIT_STATE ( xfs_buf_write_fail_rl_state , 30 * HZ , 10 ) ;
xfs: abort metadata writeback on permanent errors
If we are doing aysnc writeback of metadata, we can get write errors
but have nobody to report them to. At the moment, we simply attempt
to reissue the write from io completion in the hope that it's a
transient error.
When it's not a transient error, the buffer is stuck forever in
this loop, and we cannot break out of it. Eventually, unmount will
hang because the AIL cannot be emptied and everything goes downhill
from them.
To solve this problem, only retry the write IO once before aborting
it. We don't throw the buffer away because some transient errors can
last minutes (e.g. FC path failover) or even hours (thin
provisioned devices that have run out of backing space) before they
go away. Hence we really want to keep trying until we can't try any
more.
Because the buffer was not cleaned, however, it does not get removed
from the AIL and hence the next pass across the AIL will start IO on
it again. As such, we still get the "retry forever" semantics that
we currently have, but we allow other access to the buffer in the
mean time. Meanwhile the filesystem can continue to modify the
buffer and relog it, so the IO errors won't hang the log or the
filesystem.
Now when we are pushing the AIL, we can see all these "permanent IO
error" buffers and we can issue a warning about failures before we
retry the IO. We can also catch these buffers when unmounting an
issue a corruption warning, too.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ben Myers <bpm@sgi.com>
2013-12-12 09:34:38 +04:00
2005-06-21 09:36:52 +04:00
STATIC uint
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +04:00
xfs_buf_item_push (
struct xfs_log_item * lip ,
struct list_head * buffer_list )
2005-04-17 02:20:36 +04:00
{
2010-06-23 12:11:15 +04:00
struct xfs_buf_log_item * bip = BUF_ITEM ( lip ) ;
struct xfs_buf * bp = bip - > bli_buf ;
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +04:00
uint rval = XFS_ITEM_SUCCESS ;
2005-04-17 02:20:36 +04:00
2011-07-23 03:40:27 +04:00
if ( xfs_buf_ispinned ( bp ) )
2005-04-17 02:20:36 +04:00
return XFS_ITEM_PINNED ;
2013-02-11 19:08:21 +04:00
if ( ! xfs_buf_trylock ( bp ) ) {
/*
* If we have just raced with a buffer being pinned and it has
* been marked stale , we could end up stalling until someone else
* issues a log force to unpin the stale buffer . Check for the
* race condition here so xfsaild recognizes the buffer is pinned
* and queues a log force to move it along .
*/
if ( xfs_buf_ispinned ( bp ) )
return XFS_ITEM_PINNED ;
2005-04-17 02:20:36 +04:00
return XFS_ITEM_LOCKED ;
2013-02-11 19:08:21 +04:00
}
2005-04-17 02:20:36 +04:00
ASSERT ( ! ( bip - > bli_flags & XFS_BLI_STALE ) ) ;
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +04:00
trace_xfs_buf_item_push ( bip ) ;
xfs: abort metadata writeback on permanent errors
If we are doing aysnc writeback of metadata, we can get write errors
but have nobody to report them to. At the moment, we simply attempt
to reissue the write from io completion in the hope that it's a
transient error.
When it's not a transient error, the buffer is stuck forever in
this loop, and we cannot break out of it. Eventually, unmount will
hang because the AIL cannot be emptied and everything goes downhill
from them.
To solve this problem, only retry the write IO once before aborting
it. We don't throw the buffer away because some transient errors can
last minutes (e.g. FC path failover) or even hours (thin
provisioned devices that have run out of backing space) before they
go away. Hence we really want to keep trying until we can't try any
more.
Because the buffer was not cleaned, however, it does not get removed
from the AIL and hence the next pass across the AIL will start IO on
it again. As such, we still get the "retry forever" semantics that
we currently have, but we allow other access to the buffer in the
mean time. Meanwhile the filesystem can continue to modify the
buffer and relog it, so the IO errors won't hang the log or the
filesystem.
Now when we are pushing the AIL, we can see all these "permanent IO
error" buffers and we can issue a warning about failures before we
retry the IO. We can also catch these buffers when unmounting an
issue a corruption warning, too.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ben Myers <bpm@sgi.com>
2013-12-12 09:34:38 +04:00
/* has a previous flush failed due to IO errors? */
if ( ( bp - > b_flags & XBF_WRITE_FAIL ) & &
2015-02-24 02:14:04 +03:00
___ratelimit ( & xfs_buf_write_fail_rl_state , " XFS: Failing async write " ) ) {
2019-06-29 05:27:29 +03:00
xfs_warn ( bp - > b_mount ,
2015-02-24 02:14:04 +03:00
" Failing async write on buffer block 0x%llx. Retrying async write. " ,
xfs: abort metadata writeback on permanent errors
If we are doing aysnc writeback of metadata, we can get write errors
but have nobody to report them to. At the moment, we simply attempt
to reissue the write from io completion in the hope that it's a
transient error.
When it's not a transient error, the buffer is stuck forever in
this loop, and we cannot break out of it. Eventually, unmount will
hang because the AIL cannot be emptied and everything goes downhill
from them.
To solve this problem, only retry the write IO once before aborting
it. We don't throw the buffer away because some transient errors can
last minutes (e.g. FC path failover) or even hours (thin
provisioned devices that have run out of backing space) before they
go away. Hence we really want to keep trying until we can't try any
more.
Because the buffer was not cleaned, however, it does not get removed
from the AIL and hence the next pass across the AIL will start IO on
it again. As such, we still get the "retry forever" semantics that
we currently have, but we allow other access to the buffer in the
mean time. Meanwhile the filesystem can continue to modify the
buffer and relog it, so the IO errors won't hang the log or the
filesystem.
Now when we are pushing the AIL, we can see all these "permanent IO
error" buffers and we can issue a warning about failures before we
retry the IO. We can also catch these buffers when unmounting an
issue a corruption warning, too.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ben Myers <bpm@sgi.com>
2013-12-12 09:34:38 +04:00
( long long ) bp - > b_bn ) ;
}
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +04:00
if ( ! xfs_buf_delwri_queue ( bp , buffer_list ) )
rval = XFS_ITEM_FLUSHING ;
xfs_buf_unlock ( bp ) ;
return rval ;
2005-04-17 02:20:36 +04:00
}
xfs: refactor xfs_buf_log_item reference count handling
The xfs_buf_log_item structure has a reference counter with slightly
tricky semantics. In the common case, a buffer is logged and
committed in a transaction, committed to the on-disk log (added to
the AIL) and then finally written back and removed from the AIL. The
bli refcount covers two potentially overlapping timeframes:
1. the bli is held in an active transaction
2. the bli is pinned by the log
The caveat to this approach is that the reference counter does not
purely dictate the lifetime of the bli. IOW, when a dirty buffer is
physically logged and unpinned, the bli refcount may go to zero as
the log item is inserted into the AIL. Only once the buffer is
written back can the bli finally be freed.
The above semantics means that it is not enough for the various
refcount decrementing contexts to release the bli on decrement to
zero. xfs_trans_brelse(), transaction commit (->iop_unlock()) and
unpin (->iop_unpin()) must all drop the associated reference and
make additional checks to determine if the current context is
responsible for freeing the item.
For example, if a transaction holds but does not dirty a particular
bli, the commit may drop the refcount to zero. If the bli itself is
clean, it is also not AIL resident and must be freed at this time.
The same is true for xfs_trans_brelse(). If the transaction dirties
a bli and then aborts or an unpin results in an abort due to a log
I/O error, the last reference count holder is expected to explicitly
remove the item from the AIL and release it (since an abort means
filesystem shutdown and metadata writeback will never occur).
This leads to fairly complex checks being replicated in a few
different places. Since ->iop_unlock() and xfs_trans_brelse() are
nearly identical, refactor the logic into a common helper that
implements and documents the semantics in one place. This patch does
not change behavior.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-09-29 06:45:26 +03:00
/*
* Drop the buffer log item refcount and take appropriate action . This helper
* determines whether the bli must be freed or not , since a decrement to zero
* does not necessarily mean the bli is unused .
*
* Return true if the bli is freed , false otherwise .
*/
bool
xfs_buf_item_put (
struct xfs_buf_log_item * bip )
{
struct xfs_log_item * lip = & bip - > bli_item ;
bool aborted ;
bool dirty ;
/* drop the bli ref and return if it wasn't the last one */
if ( ! atomic_dec_and_test ( & bip - > bli_refcount ) )
return false ;
/*
* We dropped the last ref and must free the item if clean or aborted .
* If the bli is dirty and non - aborted , the buffer was clean in the
* transaction but still awaiting writeback from previous changes . In
* that case , the bli is freed on buffer writeback completion .
*/
aborted = test_bit ( XFS_LI_ABORTED , & lip - > li_flags ) | |
XFS_FORCED_SHUTDOWN ( lip - > li_mountp ) ;
dirty = bip - > bli_flags & XFS_BLI_DIRTY ;
if ( dirty & & ! aborted )
return false ;
/*
* The bli is aborted or clean . An aborted item may be in the AIL
* regardless of dirty state . For example , consider an aborted
* transaction that invalidated a dirty bli and cleared the dirty
* state .
*/
if ( aborted )
xfs_trans_ail_remove ( lip , SHUTDOWN_LOG_IO_ERROR ) ;
xfs_buf_item_relse ( bip - > bli_buf ) ;
return true ;
}
2005-04-17 02:20:36 +04:00
/*
2010-05-07 05:04:34 +04:00
* Release the buffer associated with the buf log item . If there is no dirty
* logged data associated with the buffer recorded in the buf log item , then
* free the buf log item and remove the reference to it in the buffer .
2005-04-17 02:20:36 +04:00
*
2010-05-07 05:04:34 +04:00
* This call ignores the recursion count . It is only called when the buffer
* should REALLY be unlocked , regardless of the recursion count .
2005-04-17 02:20:36 +04:00
*
2010-05-07 05:04:34 +04:00
* We unconditionally drop the transaction ' s reference to the log item . If the
* item was logged , then another reference was taken when it was pinned , so we
* can safely drop the transaction reference now . This also allows us to avoid
* potential races with the unpin code freeing the bli by not referencing the
* bli after we ' ve dropped the reference count .
*
* If the XFS_BLI_HOLD flag is set in the buf log item , then free the log item
* if necessary but do not unlock the buffer . This is for support of
* xfs_trans_bhold ( ) . Make sure the XFS_BLI_HOLD field is cleared if we don ' t
* free the item .
2005-04-17 02:20:36 +04:00
*/
2005-06-21 09:36:52 +04:00
STATIC void
2019-06-29 05:27:32 +03:00
xfs_buf_item_release (
2010-06-23 12:11:15 +04:00
struct xfs_log_item * lip )
2005-04-17 02:20:36 +04:00
{
2010-06-23 12:11:15 +04:00
struct xfs_buf_log_item * bip = BUF_ITEM ( lip ) ;
struct xfs_buf * bp = bip - > bli_buf ;
xfs: refactor xfs_buf_log_item reference count handling
The xfs_buf_log_item structure has a reference counter with slightly
tricky semantics. In the common case, a buffer is logged and
committed in a transaction, committed to the on-disk log (added to
the AIL) and then finally written back and removed from the AIL. The
bli refcount covers two potentially overlapping timeframes:
1. the bli is held in an active transaction
2. the bli is pinned by the log
The caveat to this approach is that the reference counter does not
purely dictate the lifetime of the bli. IOW, when a dirty buffer is
physically logged and unpinned, the bli refcount may go to zero as
the log item is inserted into the AIL. Only once the buffer is
written back can the bli finally be freed.
The above semantics means that it is not enough for the various
refcount decrementing contexts to release the bli on decrement to
zero. xfs_trans_brelse(), transaction commit (->iop_unlock()) and
unpin (->iop_unpin()) must all drop the associated reference and
make additional checks to determine if the current context is
responsible for freeing the item.
For example, if a transaction holds but does not dirty a particular
bli, the commit may drop the refcount to zero. If the bli itself is
clean, it is also not AIL resident and must be freed at this time.
The same is true for xfs_trans_brelse(). If the transaction dirties
a bli and then aborts or an unpin results in an abort due to a log
I/O error, the last reference count holder is expected to explicitly
remove the item from the AIL and release it (since an abort means
filesystem shutdown and metadata writeback will never occur).
This leads to fairly complex checks being replicated in a few
different places. Since ->iop_unlock() and xfs_trans_brelse() are
nearly identical, refactor the logic into a common helper that
implements and documents the semantics in one place. This patch does
not change behavior.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-09-29 06:45:26 +03:00
bool released ;
xfs: don't unlock invalidated buf on aborted tx commit
xfstests generic/388,475 occasionally reproduce assertion failures
in xfs_buf_item_unpin() when the final bli reference is dropped on
an invalidated buffer and the buffer is not locked as it is expected
to be. Invalidated buffers should remain locked on transaction
commit until the final unpin, at which point the buffer is removed
from the AIL and the bli is freed since stale buffers are not
written back.
The assert failures are associated with filesystem shutdown,
typically due to log I/O errors injected by the test. The
problematic situation can occur if the shutdown happens to cause a
race between an active transaction that has invalidated a particular
buffer and an I/O error on a log buffer that contains the bli
associated with the same (now stale) buffer.
Both transaction and log contexts acquire a bli reference. If the
transaction has already invalidated the buffer by the time the I/O
error occurs and ends up aborting due to shutdown, the transaction
and log hold the last two references to a stale bli. If the
transaction cancel occurs first, it treats the buffer as non-stale
due to the aborted state: the bli reference is dropped and the
buffer is released/unlocked. The log buffer I/O error handling
eventually calls into xfs_buf_item_unpin(), drops the final
reference to the bli and treats it as stale. The buffer wasn't left
locked by xfs_buf_item_unlock(), however, so the assert fails and
the buffer is double unlocked. The latter problem is mitigated by
the fact that the fs is shutdown and no further damage is possible.
->iop_unlock() of an invalidated buffer should behave consistently
with respect to the bli refcount, regardless of aborted state. If
the refcount remains elevated on commit, we know the bli is awaiting
an unpin (since it can't be in another transaction) and will be
handled appropriately on log buffer completion. If the final bli
reference of an invalidated buffer is dropped in ->iop_unlock(), we
can assume the transaction has aborted because invalidation implies
a dirty transaction. In the non-abort case, the log would have
acquired a bli reference in ->iop_pin() and prevented bli release at
->iop_unlock() time. In the abort case the item must be freed and
buffer unlocked because it wasn't pinned by the log.
Rework xfs_buf_item_unlock() to simplify the currently circuitous
and duplicate logic and leave invalidated buffers locked based on
bli refcount, regardless of aborted state. This ensures that a
pinned, stale buffer is always found locked when eventually
unpinned.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-09-29 06:44:40 +03:00
bool hold = bip - > bli_flags & XFS_BLI_HOLD ;
bool stale = bip - > bli_flags & XFS_BLI_STALE ;
2017-09-01 01:11:06 +03:00
# if defined(DEBUG) || defined(XFS_WARN)
xfs: don't unlock invalidated buf on aborted tx commit
xfstests generic/388,475 occasionally reproduce assertion failures
in xfs_buf_item_unpin() when the final bli reference is dropped on
an invalidated buffer and the buffer is not locked as it is expected
to be. Invalidated buffers should remain locked on transaction
commit until the final unpin, at which point the buffer is removed
from the AIL and the bli is freed since stale buffers are not
written back.
The assert failures are associated with filesystem shutdown,
typically due to log I/O errors injected by the test. The
problematic situation can occur if the shutdown happens to cause a
race between an active transaction that has invalidated a particular
buffer and an I/O error on a log buffer that contains the bli
associated with the same (now stale) buffer.
Both transaction and log contexts acquire a bli reference. If the
transaction has already invalidated the buffer by the time the I/O
error occurs and ends up aborting due to shutdown, the transaction
and log hold the last two references to a stale bli. If the
transaction cancel occurs first, it treats the buffer as non-stale
due to the aborted state: the bli reference is dropped and the
buffer is released/unlocked. The log buffer I/O error handling
eventually calls into xfs_buf_item_unpin(), drops the final
reference to the bli and treats it as stale. The buffer wasn't left
locked by xfs_buf_item_unlock(), however, so the assert fails and
the buffer is double unlocked. The latter problem is mitigated by
the fact that the fs is shutdown and no further damage is possible.
->iop_unlock() of an invalidated buffer should behave consistently
with respect to the bli refcount, regardless of aborted state. If
the refcount remains elevated on commit, we know the bli is awaiting
an unpin (since it can't be in another transaction) and will be
handled appropriately on log buffer completion. If the final bli
reference of an invalidated buffer is dropped in ->iop_unlock(), we
can assume the transaction has aborted because invalidation implies
a dirty transaction. In the non-abort case, the log would have
acquired a bli reference in ->iop_pin() and prevented bli release at
->iop_unlock() time. In the abort case the item must be freed and
buffer unlocked because it wasn't pinned by the log.
Rework xfs_buf_item_unlock() to simplify the currently circuitous
and duplicate logic and leave invalidated buffers locked based on
bli refcount, regardless of aborted state. This ensures that a
pinned, stale buffer is always found locked when eventually
unpinned.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-09-29 06:44:40 +03:00
bool ordered = bip - > bli_flags & XFS_BLI_ORDERED ;
xfs: refactor xfs_buf_log_item reference count handling
The xfs_buf_log_item structure has a reference counter with slightly
tricky semantics. In the common case, a buffer is logged and
committed in a transaction, committed to the on-disk log (added to
the AIL) and then finally written back and removed from the AIL. The
bli refcount covers two potentially overlapping timeframes:
1. the bli is held in an active transaction
2. the bli is pinned by the log
The caveat to this approach is that the reference counter does not
purely dictate the lifetime of the bli. IOW, when a dirty buffer is
physically logged and unpinned, the bli refcount may go to zero as
the log item is inserted into the AIL. Only once the buffer is
written back can the bli finally be freed.
The above semantics means that it is not enough for the various
refcount decrementing contexts to release the bli on decrement to
zero. xfs_trans_brelse(), transaction commit (->iop_unlock()) and
unpin (->iop_unpin()) must all drop the associated reference and
make additional checks to determine if the current context is
responsible for freeing the item.
For example, if a transaction holds but does not dirty a particular
bli, the commit may drop the refcount to zero. If the bli itself is
clean, it is also not AIL resident and must be freed at this time.
The same is true for xfs_trans_brelse(). If the transaction dirties
a bli and then aborts or an unpin results in an abort due to a log
I/O error, the last reference count holder is expected to explicitly
remove the item from the AIL and release it (since an abort means
filesystem shutdown and metadata writeback will never occur).
This leads to fairly complex checks being replicated in a few
different places. Since ->iop_unlock() and xfs_trans_brelse() are
nearly identical, refactor the logic into a common helper that
implements and documents the semantics in one place. This patch does
not change behavior.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-09-29 06:45:26 +03:00
bool dirty = bip - > bli_flags & XFS_BLI_DIRTY ;
2019-04-12 17:39:19 +03:00
bool aborted = test_bit ( XFS_LI_ABORTED ,
& lip - > li_flags ) ;
2017-09-01 01:11:06 +03:00
# endif
2005-04-17 02:20:36 +04:00
2019-06-29 05:27:32 +03:00
trace_xfs_buf_item_release ( bip ) ;
2005-04-17 02:20:36 +04:00
/*
2017-08-29 20:08:37 +03:00
* The bli dirty state should match whether the blf has logged segments
* except for ordered buffers , where only the bli should be dirty .
2005-04-17 02:20:36 +04:00
*/
2017-08-29 20:08:37 +03:00
ASSERT ( ( ! ordered & & dirty = = xfs_buf_item_dirty_format ( bip ) ) | |
( ordered & & dirty & & ! xfs_buf_item_dirty_format ( bip ) ) ) ;
xfs: don't unlock invalidated buf on aborted tx commit
xfstests generic/388,475 occasionally reproduce assertion failures
in xfs_buf_item_unpin() when the final bli reference is dropped on
an invalidated buffer and the buffer is not locked as it is expected
to be. Invalidated buffers should remain locked on transaction
commit until the final unpin, at which point the buffer is removed
from the AIL and the bli is freed since stale buffers are not
written back.
The assert failures are associated with filesystem shutdown,
typically due to log I/O errors injected by the test. The
problematic situation can occur if the shutdown happens to cause a
race between an active transaction that has invalidated a particular
buffer and an I/O error on a log buffer that contains the bli
associated with the same (now stale) buffer.
Both transaction and log contexts acquire a bli reference. If the
transaction has already invalidated the buffer by the time the I/O
error occurs and ends up aborting due to shutdown, the transaction
and log hold the last two references to a stale bli. If the
transaction cancel occurs first, it treats the buffer as non-stale
due to the aborted state: the bli reference is dropped and the
buffer is released/unlocked. The log buffer I/O error handling
eventually calls into xfs_buf_item_unpin(), drops the final
reference to the bli and treats it as stale. The buffer wasn't left
locked by xfs_buf_item_unlock(), however, so the assert fails and
the buffer is double unlocked. The latter problem is mitigated by
the fact that the fs is shutdown and no further damage is possible.
->iop_unlock() of an invalidated buffer should behave consistently
with respect to the bli refcount, regardless of aborted state. If
the refcount remains elevated on commit, we know the bli is awaiting
an unpin (since it can't be in another transaction) and will be
handled appropriately on log buffer completion. If the final bli
reference of an invalidated buffer is dropped in ->iop_unlock(), we
can assume the transaction has aborted because invalidation implies
a dirty transaction. In the non-abort case, the log would have
acquired a bli reference in ->iop_pin() and prevented bli release at
->iop_unlock() time. In the abort case the item must be freed and
buffer unlocked because it wasn't pinned by the log.
Rework xfs_buf_item_unlock() to simplify the currently circuitous
and duplicate logic and leave invalidated buffers locked based on
bli refcount, regardless of aborted state. This ensures that a
pinned, stale buffer is always found locked when eventually
unpinned.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-09-29 06:44:40 +03:00
ASSERT ( ! stale | | ( bip - > __bli_format . blf_flags & XFS_BLF_CANCEL ) ) ;
2013-09-03 15:47:37 +04:00
/*
xfs: don't unlock invalidated buf on aborted tx commit
xfstests generic/388,475 occasionally reproduce assertion failures
in xfs_buf_item_unpin() when the final bli reference is dropped on
an invalidated buffer and the buffer is not locked as it is expected
to be. Invalidated buffers should remain locked on transaction
commit until the final unpin, at which point the buffer is removed
from the AIL and the bli is freed since stale buffers are not
written back.
The assert failures are associated with filesystem shutdown,
typically due to log I/O errors injected by the test. The
problematic situation can occur if the shutdown happens to cause a
race between an active transaction that has invalidated a particular
buffer and an I/O error on a log buffer that contains the bli
associated with the same (now stale) buffer.
Both transaction and log contexts acquire a bli reference. If the
transaction has already invalidated the buffer by the time the I/O
error occurs and ends up aborting due to shutdown, the transaction
and log hold the last two references to a stale bli. If the
transaction cancel occurs first, it treats the buffer as non-stale
due to the aborted state: the bli reference is dropped and the
buffer is released/unlocked. The log buffer I/O error handling
eventually calls into xfs_buf_item_unpin(), drops the final
reference to the bli and treats it as stale. The buffer wasn't left
locked by xfs_buf_item_unlock(), however, so the assert fails and
the buffer is double unlocked. The latter problem is mitigated by
the fact that the fs is shutdown and no further damage is possible.
->iop_unlock() of an invalidated buffer should behave consistently
with respect to the bli refcount, regardless of aborted state. If
the refcount remains elevated on commit, we know the bli is awaiting
an unpin (since it can't be in another transaction) and will be
handled appropriately on log buffer completion. If the final bli
reference of an invalidated buffer is dropped in ->iop_unlock(), we
can assume the transaction has aborted because invalidation implies
a dirty transaction. In the non-abort case, the log would have
acquired a bli reference in ->iop_pin() and prevented bli release at
->iop_unlock() time. In the abort case the item must be freed and
buffer unlocked because it wasn't pinned by the log.
Rework xfs_buf_item_unlock() to simplify the currently circuitous
and duplicate logic and leave invalidated buffers locked based on
bli refcount, regardless of aborted state. This ensures that a
pinned, stale buffer is always found locked when eventually
unpinned.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-09-29 06:44:40 +03:00
* Clear the buffer ' s association with this transaction and
* per - transaction state from the bli , which has been copied above .
*/
bp - > b_transp = NULL ;
bip - > bli_flags & = ~ ( XFS_BLI_LOGGED | XFS_BLI_HOLD | XFS_BLI_ORDERED ) ;
/*
xfs: refactor xfs_buf_log_item reference count handling
The xfs_buf_log_item structure has a reference counter with slightly
tricky semantics. In the common case, a buffer is logged and
committed in a transaction, committed to the on-disk log (added to
the AIL) and then finally written back and removed from the AIL. The
bli refcount covers two potentially overlapping timeframes:
1. the bli is held in an active transaction
2. the bli is pinned by the log
The caveat to this approach is that the reference counter does not
purely dictate the lifetime of the bli. IOW, when a dirty buffer is
physically logged and unpinned, the bli refcount may go to zero as
the log item is inserted into the AIL. Only once the buffer is
written back can the bli finally be freed.
The above semantics means that it is not enough for the various
refcount decrementing contexts to release the bli on decrement to
zero. xfs_trans_brelse(), transaction commit (->iop_unlock()) and
unpin (->iop_unpin()) must all drop the associated reference and
make additional checks to determine if the current context is
responsible for freeing the item.
For example, if a transaction holds but does not dirty a particular
bli, the commit may drop the refcount to zero. If the bli itself is
clean, it is also not AIL resident and must be freed at this time.
The same is true for xfs_trans_brelse(). If the transaction dirties
a bli and then aborts or an unpin results in an abort due to a log
I/O error, the last reference count holder is expected to explicitly
remove the item from the AIL and release it (since an abort means
filesystem shutdown and metadata writeback will never occur).
This leads to fairly complex checks being replicated in a few
different places. Since ->iop_unlock() and xfs_trans_brelse() are
nearly identical, refactor the logic into a common helper that
implements and documents the semantics in one place. This patch does
not change behavior.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-09-29 06:45:26 +03:00
* Unref the item and unlock the buffer unless held or stale . Stale
* buffers remain locked until final unpin unless the bli is freed by
* the unref call . The latter implies shutdown because buffer
* invalidation dirties the bli and transaction .
2013-09-03 15:47:37 +04:00
*/
xfs: refactor xfs_buf_log_item reference count handling
The xfs_buf_log_item structure has a reference counter with slightly
tricky semantics. In the common case, a buffer is logged and
committed in a transaction, committed to the on-disk log (added to
the AIL) and then finally written back and removed from the AIL. The
bli refcount covers two potentially overlapping timeframes:
1. the bli is held in an active transaction
2. the bli is pinned by the log
The caveat to this approach is that the reference counter does not
purely dictate the lifetime of the bli. IOW, when a dirty buffer is
physically logged and unpinned, the bli refcount may go to zero as
the log item is inserted into the AIL. Only once the buffer is
written back can the bli finally be freed.
The above semantics means that it is not enough for the various
refcount decrementing contexts to release the bli on decrement to
zero. xfs_trans_brelse(), transaction commit (->iop_unlock()) and
unpin (->iop_unpin()) must all drop the associated reference and
make additional checks to determine if the current context is
responsible for freeing the item.
For example, if a transaction holds but does not dirty a particular
bli, the commit may drop the refcount to zero. If the bli itself is
clean, it is also not AIL resident and must be freed at this time.
The same is true for xfs_trans_brelse(). If the transaction dirties
a bli and then aborts or an unpin results in an abort due to a log
I/O error, the last reference count holder is expected to explicitly
remove the item from the AIL and release it (since an abort means
filesystem shutdown and metadata writeback will never occur).
This leads to fairly complex checks being replicated in a few
different places. Since ->iop_unlock() and xfs_trans_brelse() are
nearly identical, refactor the logic into a common helper that
implements and documents the semantics in one place. This patch does
not change behavior.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-09-29 06:45:26 +03:00
released = xfs_buf_item_put ( bip ) ;
if ( hold | | ( stale & & ! released ) )
xfs: don't unlock invalidated buf on aborted tx commit
xfstests generic/388,475 occasionally reproduce assertion failures
in xfs_buf_item_unpin() when the final bli reference is dropped on
an invalidated buffer and the buffer is not locked as it is expected
to be. Invalidated buffers should remain locked on transaction
commit until the final unpin, at which point the buffer is removed
from the AIL and the bli is freed since stale buffers are not
written back.
The assert failures are associated with filesystem shutdown,
typically due to log I/O errors injected by the test. The
problematic situation can occur if the shutdown happens to cause a
race between an active transaction that has invalidated a particular
buffer and an I/O error on a log buffer that contains the bli
associated with the same (now stale) buffer.
Both transaction and log contexts acquire a bli reference. If the
transaction has already invalidated the buffer by the time the I/O
error occurs and ends up aborting due to shutdown, the transaction
and log hold the last two references to a stale bli. If the
transaction cancel occurs first, it treats the buffer as non-stale
due to the aborted state: the bli reference is dropped and the
buffer is released/unlocked. The log buffer I/O error handling
eventually calls into xfs_buf_item_unpin(), drops the final
reference to the bli and treats it as stale. The buffer wasn't left
locked by xfs_buf_item_unlock(), however, so the assert fails and
the buffer is double unlocked. The latter problem is mitigated by
the fact that the fs is shutdown and no further damage is possible.
->iop_unlock() of an invalidated buffer should behave consistently
with respect to the bli refcount, regardless of aborted state. If
the refcount remains elevated on commit, we know the bli is awaiting
an unpin (since it can't be in another transaction) and will be
handled appropriately on log buffer completion. If the final bli
reference of an invalidated buffer is dropped in ->iop_unlock(), we
can assume the transaction has aborted because invalidation implies
a dirty transaction. In the non-abort case, the log would have
acquired a bli reference in ->iop_pin() and prevented bli release at
->iop_unlock() time. In the abort case the item must be freed and
buffer unlocked because it wasn't pinned by the log.
Rework xfs_buf_item_unlock() to simplify the currently circuitous
and duplicate logic and leave invalidated buffers locked based on
bli refcount, regardless of aborted state. This ensures that a
pinned, stale buffer is always found locked when eventually
unpinned.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-09-29 06:44:40 +03:00
return ;
2019-04-12 17:39:19 +03:00
ASSERT ( ! stale | | aborted ) ;
xfs: refactor xfs_buf_log_item reference count handling
The xfs_buf_log_item structure has a reference counter with slightly
tricky semantics. In the common case, a buffer is logged and
committed in a transaction, committed to the on-disk log (added to
the AIL) and then finally written back and removed from the AIL. The
bli refcount covers two potentially overlapping timeframes:
1. the bli is held in an active transaction
2. the bli is pinned by the log
The caveat to this approach is that the reference counter does not
purely dictate the lifetime of the bli. IOW, when a dirty buffer is
physically logged and unpinned, the bli refcount may go to zero as
the log item is inserted into the AIL. Only once the buffer is
written back can the bli finally be freed.
The above semantics means that it is not enough for the various
refcount decrementing contexts to release the bli on decrement to
zero. xfs_trans_brelse(), transaction commit (->iop_unlock()) and
unpin (->iop_unpin()) must all drop the associated reference and
make additional checks to determine if the current context is
responsible for freeing the item.
For example, if a transaction holds but does not dirty a particular
bli, the commit may drop the refcount to zero. If the bli itself is
clean, it is also not AIL resident and must be freed at this time.
The same is true for xfs_trans_brelse(). If the transaction dirties
a bli and then aborts or an unpin results in an abort due to a log
I/O error, the last reference count holder is expected to explicitly
remove the item from the AIL and release it (since an abort means
filesystem shutdown and metadata writeback will never occur).
This leads to fairly complex checks being replicated in a few
different places. Since ->iop_unlock() and xfs_trans_brelse() are
nearly identical, refactor the logic into a common helper that
implements and documents the semantics in one place. This patch does
not change behavior.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-09-29 06:45:26 +03:00
xfs_buf_relse ( bp ) ;
2005-04-17 02:20:36 +04:00
}
2019-06-29 05:27:32 +03:00
STATIC void
xfs_buf_item_committing (
struct xfs_log_item * lip ,
xfs_lsn_t commit_lsn )
{
return xfs_buf_item_release ( lip ) ;
}
2005-04-17 02:20:36 +04:00
/*
* This is called to find out where the oldest active copy of the
* buf log item in the on disk log resides now that the last log
* write of it completed at the given lsn .
* We always re - log all the dirty data in a buffer , so usually the
* latest copy in the on disk log is the only one that matters . For
* those cases we simply return the given lsn .
*
* The one exception to this is for buffers full of newly allocated
* inodes . These buffers are only relogged with the XFS_BLI_INODE_BUF
* flag set , indicating that only the di_next_unlinked fields from the
* inodes in the buffers will be replayed during recovery . If the
* original newly allocated inode images have not yet been flushed
* when the buffer is so relogged , then we need to make sure that we
* keep the old images in the ' active ' portion of the log . We do this
* by returning the original lsn of that transaction here rather than
* the current one .
*/
2005-06-21 09:36:52 +04:00
STATIC xfs_lsn_t
2005-04-17 02:20:36 +04:00
xfs_buf_item_committed (
2010-06-23 12:11:15 +04:00
struct xfs_log_item * lip ,
2005-04-17 02:20:36 +04:00
xfs_lsn_t lsn )
{
2010-06-23 12:11:15 +04:00
struct xfs_buf_log_item * bip = BUF_ITEM ( lip ) ;
2009-12-15 02:14:59 +03:00
trace_xfs_buf_item_committed ( bip ) ;
2010-06-23 12:11:15 +04:00
if ( ( bip - > bli_flags & XFS_BLI_INODE_ALLOC_BUF ) & & lip - > li_lsn ! = 0 )
return lip - > li_lsn ;
return lsn ;
2005-04-17 02:20:36 +04:00
}
2011-10-28 13:54:24 +04:00
static const struct xfs_item_ops xfs_buf_item_ops = {
2010-06-23 12:11:15 +04:00
. iop_size = xfs_buf_item_size ,
. iop_format = xfs_buf_item_format ,
. iop_pin = xfs_buf_item_pin ,
. iop_unpin = xfs_buf_item_unpin ,
2019-06-29 05:27:32 +03:00
. iop_release = xfs_buf_item_release ,
. iop_committing = xfs_buf_item_committing ,
2010-06-23 12:11:15 +04:00
. iop_committed = xfs_buf_item_committed ,
. iop_push = xfs_buf_item_push ,
2005-04-17 02:20:36 +04:00
} ;
2020-01-08 20:21:22 +03:00
STATIC void
2012-06-22 12:50:12 +04:00
xfs_buf_item_get_format (
struct xfs_buf_log_item * bip ,
int count )
{
ASSERT ( bip - > bli_formats = = NULL ) ;
bip - > bli_format_count = count ;
if ( count = = 1 ) {
2012-12-05 03:18:03 +04:00
bip - > bli_formats = & bip - > __bli_format ;
2020-01-08 20:21:22 +03:00
return ;
2012-06-22 12:50:12 +04:00
}
bip - > bli_formats = kmem_zalloc ( count * sizeof ( struct xfs_buf_log_format ) ,
2019-08-26 22:06:22 +03:00
0 ) ;
2012-06-22 12:50:12 +04:00
}
STATIC void
xfs_buf_item_free_format (
struct xfs_buf_log_item * bip )
{
2012-12-05 03:18:03 +04:00
if ( bip - > bli_formats ! = & bip - > __bli_format ) {
2012-06-22 12:50:12 +04:00
kmem_free ( bip - > bli_formats ) ;
bip - > bli_formats = NULL ;
}
}
2005-04-17 02:20:36 +04:00
/*
* Allocate a new buf log item to go with the given buffer .
2018-01-25 00:38:48 +03:00
* Set the buffer ' s b_log_item field to point to the new
* buf log item .
2005-04-17 02:20:36 +04:00
*/
2015-08-25 03:05:13 +03:00
int
2005-04-17 02:20:36 +04:00
xfs_buf_item_init (
2015-08-25 03:05:13 +03:00
struct xfs_buf * bp ,
struct xfs_mount * mp )
2005-04-17 02:20:36 +04:00
{
2018-01-25 00:38:48 +03:00
struct xfs_buf_log_item * bip = bp - > b_log_item ;
2005-04-17 02:20:36 +04:00
int chunks ;
int map_size ;
2012-06-22 12:50:12 +04:00
int i ;
2005-04-17 02:20:36 +04:00
/*
* Check to see if there is already a buf log item for
2018-01-25 00:38:48 +03:00
* this buffer . If we do already have one , there is
2005-04-17 02:20:36 +04:00
* nothing to do here so return .
*/
2019-06-29 05:27:29 +03:00
ASSERT ( bp - > b_mount = = mp ) ;
2018-05-09 17:49:10 +03:00
if ( bip ) {
2018-01-25 00:38:48 +03:00
ASSERT ( bip - > bli_item . li_type = = XFS_LI_BUF ) ;
2018-05-09 17:49:10 +03:00
ASSERT ( ! bp - > b_transp ) ;
ASSERT ( bip - > bli_buf = = bp ) ;
2015-08-25 03:05:13 +03:00
return 0 ;
2018-01-25 00:38:48 +03:00
}
2005-04-17 02:20:36 +04:00
2019-08-26 22:06:22 +03:00
bip = kmem_zone_zalloc ( xfs_buf_item_zone , 0 ) ;
2010-03-23 02:10:00 +03:00
xfs_log_item_init ( mp , & bip - > bli_item , XFS_LI_BUF , & xfs_buf_item_ops ) ;
2005-04-17 02:20:36 +04:00
bip - > bli_buf = bp ;
2012-06-22 12:50:12 +04:00
/*
* chunks is the number of XFS_BLF_CHUNK size pieces the buffer
* can be divided into . Make sure not to truncate any pieces .
* map_size is the size of the bitmap needed to describe the
* chunks of the buffer .
*
* Discontiguous buffer support follows the layout of the underlying
* buffer . This makes the implementation as simple as possible .
*/
2020-01-08 20:21:22 +03:00
xfs_buf_item_get_format ( bip , bp - > b_map_count ) ;
2012-06-22 12:50:12 +04:00
for ( i = 0 ; i < bip - > bli_format_count ; i + + ) {
chunks = DIV_ROUND_UP ( BBTOB ( bp - > b_maps [ i ] . bm_len ) ,
XFS_BLF_CHUNK ) ;
map_size = DIV_ROUND_UP ( chunks , NBWORD ) ;
2020-01-08 03:12:24 +03:00
if ( map_size > XFS_BLF_DATAMAP_SIZE ) {
kmem_cache_free ( xfs_buf_item_zone , bip ) ;
xfs_err ( mp ,
" buffer item dirty bitmap (%u uints) too small to reflect %u bytes! " ,
map_size ,
BBTOB ( bp - > b_maps [ i ] . bm_len ) ) ;
return - EFSCORRUPTED ;
}
2012-06-22 12:50:12 +04:00
bip - > bli_formats [ i ] . blf_type = XFS_LI_BUF ;
bip - > bli_formats [ i ] . blf_blkno = bp - > b_maps [ i ] . bm_bn ;
bip - > bli_formats [ i ] . blf_len = bp - > b_maps [ i ] . bm_len ;
bip - > bli_formats [ i ] . blf_map_size = map_size ;
}
2005-04-17 02:20:36 +04:00
2018-01-25 00:38:48 +03:00
bp - > b_log_item = bip ;
2015-08-25 03:05:13 +03:00
xfs_buf_hold ( bp ) ;
return 0 ;
2005-04-17 02:20:36 +04:00
}
/*
* Mark bytes first through last inclusive as dirty in the buf
* item ' s bitmap .
*/
2013-10-29 15:11:58 +04:00
static void
2012-06-22 12:50:12 +04:00
xfs_buf_item_log_segment (
2005-04-17 02:20:36 +04:00
uint first ,
2012-06-22 12:50:12 +04:00
uint last ,
uint * map )
2005-04-17 02:20:36 +04:00
{
uint first_bit ;
uint last_bit ;
uint bits_to_set ;
uint bits_set ;
uint word_num ;
uint * wordp ;
uint bit ;
uint end_bit ;
uint mask ;
2020-01-08 03:12:24 +03:00
ASSERT ( first < XFS_BLF_DATAMAP_SIZE * XFS_BLF_CHUNK * NBWORD ) ;
ASSERT ( last < XFS_BLF_DATAMAP_SIZE * XFS_BLF_CHUNK * NBWORD ) ;
2005-04-17 02:20:36 +04:00
/*
* Convert byte offsets to bit numbers .
*/
2010-05-07 05:05:19 +04:00
first_bit = first > > XFS_BLF_SHIFT ;
last_bit = last > > XFS_BLF_SHIFT ;
2005-04-17 02:20:36 +04:00
/*
* Calculate the total number of bits to be set .
*/
bits_to_set = last_bit - first_bit + 1 ;
/*
* Get a pointer to the first word in the bitmap
* to set a bit in .
*/
word_num = first_bit > > BIT_TO_WORD_SHIFT ;
2012-06-22 12:50:12 +04:00
wordp = & map [ word_num ] ;
2005-04-17 02:20:36 +04:00
/*
* Calculate the starting bit in the first word .
*/
bit = first_bit & ( uint ) ( NBWORD - 1 ) ;
/*
* First set any bits in the first word of our range .
* If it starts at bit 0 of the word , it will be
* set below rather than here . That is what the variable
* bit tells us . The variable bits_set tracks the number
* of bits that have been set so far . End_bit is the number
* of the last bit to be set in this word plus one .
*/
if ( bit ) {
2018-06-07 17:54:02 +03:00
end_bit = min ( bit + bits_to_set , ( uint ) NBWORD ) ;
2016-09-14 00:41:16 +03:00
mask = ( ( 1U < < ( end_bit - bit ) ) - 1 ) < < bit ;
2005-04-17 02:20:36 +04:00
* wordp | = mask ;
wordp + + ;
bits_set = end_bit - bit ;
} else {
bits_set = 0 ;
}
/*
* Now set bits a whole word at a time that are between
* first_bit and last_bit .
*/
while ( ( bits_to_set - bits_set ) > = NBWORD ) {
2019-11-06 19:58:33 +03:00
* wordp = 0xffffffff ;
2005-04-17 02:20:36 +04:00
bits_set + = NBWORD ;
wordp + + ;
}
/*
* Finally , set any bits left to be set in one last partial word .
*/
end_bit = bits_to_set - bits_set ;
if ( end_bit ) {
2016-09-14 00:41:16 +03:00
mask = ( 1U < < end_bit ) - 1 ;
2005-04-17 02:20:36 +04:00
* wordp | = mask ;
}
}
2012-06-22 12:50:12 +04:00
/*
* Mark bytes first through last inclusive as dirty in the buf
* item ' s bitmap .
*/
void
xfs_buf_item_log (
2018-01-25 00:38:48 +03:00
struct xfs_buf_log_item * bip ,
2012-06-22 12:50:12 +04:00
uint first ,
uint last )
{
int i ;
uint start ;
uint end ;
struct xfs_buf * bp = bip - > bli_buf ;
/*
* walk each buffer segment and mark them dirty appropriately .
*/
start = 0 ;
for ( i = 0 ; i < bip - > bli_format_count ; i + + ) {
if ( start > last )
break ;
xfs: fix broken multi-fsb buffer logging
Multi-block buffers are logged based on buffer offset in
xfs_trans_log_buf(). xfs_buf_item_log() ultimately walks each mapping in
the buffer and marks the associated range to be logged in the
xfs_buf_log_format bitmap for that mapping. This code is broken,
however, in that it marks the actual buffer offsets of the associated
range in each bitmap rather than shifting to the byte range for that
particular mapping.
For example, on a 4k fsb fs, buffer offset 4096 refers to the first byte
of the second mapping in the buffer. This means byte 0 of the second log
format bitmap should be tagged as dirty. Instead, the current code marks
byte offset 4096 of the second log format bitmap, which is invalid and
potentially out of range of the mapping.
As a result of this, the log item format code invoked at transaction
commit time is not be able to correctly identify what parts of the
buffer to copy into log vectors. This can lead to NULL log vector
pointer dereferences in CIL push context if the item format code was not
able to locate any dirty ranges at all. This crash has been reproduced
on a 4k FSB filesystem using 16k directory blocks where an unlink
operation happened not to log anything in the first block of the
mapping. The logged offsets were all over 4k, marked as such in the
subsequent log format mappings, and thus left the transaction with an
xfs_log_item that is marked DIRTY but without any logged regions.
Further, even when the logged regions are marked correctly in the buffer
log format bitmaps, the format code doesn't copy the correct ranges of
the buffer into the log. This means that any logged region beyond the
first block of a multi-block buffer is subject to corruption after a
crash and log recovery sequence. This is due to a failure to convert the
mapping bm_len field from basic blocks to bytes in the buffer offset
tracking code in xfs_buf_item_format().
Update xfs_buf_item_log() to convert buffer offsets to segment relative
offsets when logging multi-block buffers. This ensures that the modified
regions of a buffer are logged correctly and avoids the aforementioned
crash. Also update xfs_buf_item_format() to correctly track the source
offset into the buffer for the log vector formatting code. This ensures
that the correct data is copied into the log.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-06-01 10:38:12 +03:00
end = start + BBTOB ( bp - > b_maps [ i ] . bm_len ) - 1 ;
/* skip to the map that includes the first byte to log */
2012-06-22 12:50:12 +04:00
if ( first > end ) {
start + = BBTOB ( bp - > b_maps [ i ] . bm_len ) ;
continue ;
}
xfs: fix broken multi-fsb buffer logging
Multi-block buffers are logged based on buffer offset in
xfs_trans_log_buf(). xfs_buf_item_log() ultimately walks each mapping in
the buffer and marks the associated range to be logged in the
xfs_buf_log_format bitmap for that mapping. This code is broken,
however, in that it marks the actual buffer offsets of the associated
range in each bitmap rather than shifting to the byte range for that
particular mapping.
For example, on a 4k fsb fs, buffer offset 4096 refers to the first byte
of the second mapping in the buffer. This means byte 0 of the second log
format bitmap should be tagged as dirty. Instead, the current code marks
byte offset 4096 of the second log format bitmap, which is invalid and
potentially out of range of the mapping.
As a result of this, the log item format code invoked at transaction
commit time is not be able to correctly identify what parts of the
buffer to copy into log vectors. This can lead to NULL log vector
pointer dereferences in CIL push context if the item format code was not
able to locate any dirty ranges at all. This crash has been reproduced
on a 4k FSB filesystem using 16k directory blocks where an unlink
operation happened not to log anything in the first block of the
mapping. The logged offsets were all over 4k, marked as such in the
subsequent log format mappings, and thus left the transaction with an
xfs_log_item that is marked DIRTY but without any logged regions.
Further, even when the logged regions are marked correctly in the buffer
log format bitmaps, the format code doesn't copy the correct ranges of
the buffer into the log. This means that any logged region beyond the
first block of a multi-block buffer is subject to corruption after a
crash and log recovery sequence. This is due to a failure to convert the
mapping bm_len field from basic blocks to bytes in the buffer offset
tracking code in xfs_buf_item_format().
Update xfs_buf_item_log() to convert buffer offsets to segment relative
offsets when logging multi-block buffers. This ensures that the modified
regions of a buffer are logged correctly and avoids the aforementioned
crash. Also update xfs_buf_item_format() to correctly track the source
offset into the buffer for the log vector formatting code. This ensures
that the correct data is copied into the log.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-06-01 10:38:12 +03:00
/*
* Trim the range to this segment and mark it in the bitmap .
* Note that we must convert buffer offsets to segment relative
* offsets ( e . g . , the first byte of each segment is byte 0 of
* that segment ) .
*/
2012-06-22 12:50:12 +04:00
if ( first < start )
first = start ;
if ( end > last )
end = last ;
xfs: fix broken multi-fsb buffer logging
Multi-block buffers are logged based on buffer offset in
xfs_trans_log_buf(). xfs_buf_item_log() ultimately walks each mapping in
the buffer and marks the associated range to be logged in the
xfs_buf_log_format bitmap for that mapping. This code is broken,
however, in that it marks the actual buffer offsets of the associated
range in each bitmap rather than shifting to the byte range for that
particular mapping.
For example, on a 4k fsb fs, buffer offset 4096 refers to the first byte
of the second mapping in the buffer. This means byte 0 of the second log
format bitmap should be tagged as dirty. Instead, the current code marks
byte offset 4096 of the second log format bitmap, which is invalid and
potentially out of range of the mapping.
As a result of this, the log item format code invoked at transaction
commit time is not be able to correctly identify what parts of the
buffer to copy into log vectors. This can lead to NULL log vector
pointer dereferences in CIL push context if the item format code was not
able to locate any dirty ranges at all. This crash has been reproduced
on a 4k FSB filesystem using 16k directory blocks where an unlink
operation happened not to log anything in the first block of the
mapping. The logged offsets were all over 4k, marked as such in the
subsequent log format mappings, and thus left the transaction with an
xfs_log_item that is marked DIRTY but without any logged regions.
Further, even when the logged regions are marked correctly in the buffer
log format bitmaps, the format code doesn't copy the correct ranges of
the buffer into the log. This means that any logged region beyond the
first block of a multi-block buffer is subject to corruption after a
crash and log recovery sequence. This is due to a failure to convert the
mapping bm_len field from basic blocks to bytes in the buffer offset
tracking code in xfs_buf_item_format().
Update xfs_buf_item_log() to convert buffer offsets to segment relative
offsets when logging multi-block buffers. This ensures that the modified
regions of a buffer are logged correctly and avoids the aforementioned
crash. Also update xfs_buf_item_format() to correctly track the source
offset into the buffer for the log vector formatting code. This ensures
that the correct data is copied into the log.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-06-01 10:38:12 +03:00
xfs_buf_item_log_segment ( first - start , end - start ,
2012-06-22 12:50:12 +04:00
& bip - > bli_formats [ i ] . blf_data_map [ 0 ] ) ;
xfs: fix broken multi-fsb buffer logging
Multi-block buffers are logged based on buffer offset in
xfs_trans_log_buf(). xfs_buf_item_log() ultimately walks each mapping in
the buffer and marks the associated range to be logged in the
xfs_buf_log_format bitmap for that mapping. This code is broken,
however, in that it marks the actual buffer offsets of the associated
range in each bitmap rather than shifting to the byte range for that
particular mapping.
For example, on a 4k fsb fs, buffer offset 4096 refers to the first byte
of the second mapping in the buffer. This means byte 0 of the second log
format bitmap should be tagged as dirty. Instead, the current code marks
byte offset 4096 of the second log format bitmap, which is invalid and
potentially out of range of the mapping.
As a result of this, the log item format code invoked at transaction
commit time is not be able to correctly identify what parts of the
buffer to copy into log vectors. This can lead to NULL log vector
pointer dereferences in CIL push context if the item format code was not
able to locate any dirty ranges at all. This crash has been reproduced
on a 4k FSB filesystem using 16k directory blocks where an unlink
operation happened not to log anything in the first block of the
mapping. The logged offsets were all over 4k, marked as such in the
subsequent log format mappings, and thus left the transaction with an
xfs_log_item that is marked DIRTY but without any logged regions.
Further, even when the logged regions are marked correctly in the buffer
log format bitmaps, the format code doesn't copy the correct ranges of
the buffer into the log. This means that any logged region beyond the
first block of a multi-block buffer is subject to corruption after a
crash and log recovery sequence. This is due to a failure to convert the
mapping bm_len field from basic blocks to bytes in the buffer offset
tracking code in xfs_buf_item_format().
Update xfs_buf_item_log() to convert buffer offsets to segment relative
offsets when logging multi-block buffers. This ensures that the modified
regions of a buffer are logged correctly and avoids the aforementioned
crash. Also update xfs_buf_item_format() to correctly track the source
offset into the buffer for the log vector formatting code. This ensures
that the correct data is copied into the log.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-06-01 10:38:12 +03:00
start + = BBTOB ( bp - > b_maps [ i ] . bm_len ) ;
2012-06-22 12:50:12 +04:00
}
}
2005-04-17 02:20:36 +04:00
2017-08-29 20:08:37 +03:00
/*
* Return true if the buffer has any ranges logged / dirtied by a transaction ,
* false otherwise .
*/
bool
xfs_buf_item_dirty_format (
struct xfs_buf_log_item * bip )
{
int i ;
for ( i = 0 ; i < bip - > bli_format_count ; i + + ) {
if ( ! xfs_bitmap_empty ( bip - > bli_formats [ i ] . blf_data_map ,
bip - > bli_formats [ i ] . blf_map_size ) )
return true ;
}
return false ;
}
2008-09-17 10:52:13 +04:00
STATIC void
xfs_buf_item_free (
2018-01-25 00:38:48 +03:00
struct xfs_buf_log_item * bip )
2008-09-17 10:52:13 +04:00
{
2012-06-22 12:50:12 +04:00
xfs_buf_item_free_format ( bip ) ;
xfs: allocate log vector buffers outside CIL context lock
One of the problems we currently have with delayed logging is that
under serious memory pressure we can deadlock memory reclaim. THis
occurs when memory reclaim (such as run by kswapd) is reclaiming XFS
inodes and issues a log force to unpin inodes that are dirty in the
CIL.
The CIL is pushed, but this will only occur once it gets the CIL
context lock to ensure that all committing transactions are complete
and no new transactions start being committed to the CIL while the
push switches to a new context.
The deadlock occurs when the CIL context lock is held by a
committing process that is doing memory allocation for log vector
buffers, and that allocation is then blocked on memory reclaim
making progress. Memory reclaim, however, is blocked waiting for
a log force to make progress, and so we effectively deadlock at this
point.
To solve this problem, we have to move the CIL log vector buffer
allocation outside of the context lock so that memory reclaim can
always make progress when it needs to force the log. The problem
with doing this is that a CIL push can take place while we are
determining if we need to allocate a new log vector buffer for
an item and hence the current log vector may go away without
warning. That means we canot rely on the existing log vector being
present when we finally grab the context lock and so we must have a
replacement buffer ready to go at all times.
To ensure this, introduce a "shadow log vector" buffer that is
always guaranteed to be present when we gain the CIL context lock
and format the item. This shadow buffer may or may not be used
during the formatting, but if the log item does not have an existing
log vector buffer or that buffer is too small for the new
modifications, we swap it for the new shadow buffer and format
the modifications into that new log vector buffer.
The result of this is that for any object we modify more than once
in a given CIL checkpoint, we double the memory required
to track dirty regions in the log. For single modifications then
we consume the shadow log vectorwe allocate on commit, and that gets
consumed by the checkpoint. However, if we make multiple
modifications, then the second transaction commit will allocate a
shadow log vector and hence we will end up with double the memory
usage as only one of the log vectors is consumed by the CIL
checkpoint. The remaining shadow vector will be freed when th elog
item is freed.
This can probably be optimised in future - access to the shadow log
vector is serialised by the object lock (as opposited to the active
log vector, which is controlled by the CIL context lock) and so we
can probably free shadow log vector from some objects when the log
item is marked clean on removal from the AIL.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-07-22 02:52:35 +03:00
kmem_free ( bip - > bli_item . li_lv_shadow ) ;
2019-11-14 23:43:04 +03:00
kmem_cache_free ( xfs_buf_item_zone , bip ) ;
2008-09-17 10:52:13 +04:00
}
2005-04-17 02:20:36 +04:00
/*
* This is called when the buf log item is no longer needed . It should
* free the buf log item associated with the given buffer and clear
* the buffer ' s pointer to the buf log item . If there are no more
* items in the list , clear the b_iodone field of the buffer ( see
* xfs_buf_attach_iodone ( ) below ) .
*/
void
xfs_buf_item_relse (
xfs_buf_t * bp )
{
2018-01-25 00:38:48 +03:00
struct xfs_buf_log_item * bip = bp - > b_log_item ;
2005-04-17 02:20:36 +04:00
2009-12-15 02:14:59 +03:00
trace_xfs_buf_item_relse ( bp , _RET_IP_ ) ;
2019-12-18 00:50:26 +03:00
ASSERT ( ! test_bit ( XFS_LI_IN_AIL , & bip - > bli_item . li_flags ) ) ;
2009-12-15 02:14:59 +03:00
2018-01-25 00:38:48 +03:00
bp - > b_log_item = NULL ;
2018-01-25 00:38:49 +03:00
if ( list_empty ( & bp - > b_li_list ) )
2011-07-13 15:43:49 +04:00
bp - > b_iodone = NULL ;
2011-07-13 15:43:49 +04:00
2008-09-17 10:52:13 +04:00
xfs_buf_rele ( bp ) ;
xfs_buf_item_free ( bip ) ;
2005-04-17 02:20:36 +04:00
}
/*
* Add the given log item with its callback to the list of callbacks
* to be called when the buffer ' s I / O completes . If it is not set
* already , set the buffer ' s b_iodone ( ) routine to be
* xfs_buf_iodone_callbacks ( ) and link the log item into the list of
2018-01-25 00:38:48 +03:00
* items rooted at b_li_list .
2005-04-17 02:20:36 +04:00
*/
void
xfs_buf_attach_iodone (
2019-06-29 05:27:33 +03:00
struct xfs_buf * bp ,
void ( * cb ) ( struct xfs_buf * , struct xfs_log_item * ) ,
struct xfs_log_item * lip )
2005-04-17 02:20:36 +04:00
{
2011-07-08 16:36:19 +04:00
ASSERT ( xfs_buf_islocked ( bp ) ) ;
2005-04-17 02:20:36 +04:00
lip - > li_cb = cb ;
2018-01-25 00:38:49 +03:00
list_add_tail ( & lip - > li_bio_list , & bp - > b_li_list ) ;
2005-04-17 02:20:36 +04:00
2011-07-13 15:43:49 +04:00
ASSERT ( bp - > b_iodone = = NULL | |
bp - > b_iodone = = xfs_buf_iodone_callbacks ) ;
bp - > b_iodone = xfs_buf_iodone_callbacks ;
2005-04-17 02:20:36 +04:00
}
2010-12-03 09:00:52 +03:00
/*
* We can have many callbacks on a buffer . Running the callbacks individually
* can cause a lot of contention on the AIL lock , so we allow for a single
2018-01-25 00:38:49 +03:00
* callback to be able to scan the remaining items in bp - > b_li_list for other
* items of the same type and callback to be processed in the first call .
2010-12-03 09:00:52 +03:00
*
* As a result , the loop walking the callback list below will also modify the
* list . it removes the first item from the list and then runs the callback .
2018-01-25 00:38:49 +03:00
* The loop then restarts from the new first item int the list . This allows the
2010-12-03 09:00:52 +03:00
* callback to scan and modify the list attached to the buffer and we don ' t
* have to care about maintaining a next item pointer .
*/
2005-04-17 02:20:36 +04:00
STATIC void
xfs_buf_do_callbacks (
2010-12-03 09:00:52 +03:00
struct xfs_buf * bp )
2005-04-17 02:20:36 +04:00
{
2018-01-25 00:38:48 +03:00
struct xfs_buf_log_item * blip = bp - > b_log_item ;
2010-12-03 09:00:52 +03:00
struct xfs_log_item * lip ;
2005-04-17 02:20:36 +04:00
2018-01-25 00:38:48 +03:00
/* If there is a buf_log_item attached, run its callback */
if ( blip ) {
lip = & blip - > bli_item ;
lip - > li_cb ( bp , lip ) ;
}
2018-01-25 00:38:49 +03:00
while ( ! list_empty ( & bp - > b_li_list ) ) {
lip = list_first_entry ( & bp - > b_li_list , struct xfs_log_item ,
li_bio_list ) ;
2005-04-17 02:20:36 +04:00
/*
2018-01-25 00:38:49 +03:00
* Remove the item from the list , so we don ' t have any
2005-04-17 02:20:36 +04:00
* confusion if the item is added to another buf .
* Don ' t touch the log item after calling its
* callback , because it could have freed itself .
*/
2018-01-25 00:38:49 +03:00
list_del_init ( & lip - > li_bio_list ) ;
2005-04-17 02:20:36 +04:00
lip - > li_cb ( bp , lip ) ;
}
}
2017-08-09 04:21:50 +03:00
/*
* Invoke the error state callback for each log item affected by the failed I / O .
*
* If a metadata buffer write fails with a non - permanent error , the buffer is
* eventually resubmitted and so the completion callbacks are not run . The error
* state may need to be propagated to the log items attached to the buffer ,
* however , so the next AIL push of the item knows hot to handle it correctly .
*/
STATIC void
xfs_buf_do_callbacks_fail (
struct xfs_buf * bp )
{
2018-01-25 00:38:49 +03:00
struct xfs_log_item * lip ;
2018-01-25 00:38:48 +03:00
struct xfs_ail * ailp ;
2017-08-09 04:21:50 +03:00
2018-01-25 00:38:48 +03:00
/*
* Buffer log item errors are handled directly by xfs_buf_item_push ( )
* and xfs_buf_iodone_callback_error , and they have no IO error
* callbacks . Check only for items in b_li_list .
*/
2018-01-25 00:38:49 +03:00
if ( list_empty ( & bp - > b_li_list ) )
2018-01-25 00:38:48 +03:00
return ;
2018-01-25 00:38:49 +03:00
lip = list_first_entry ( & bp - > b_li_list , struct xfs_log_item ,
li_bio_list ) ;
2018-01-25 00:38:48 +03:00
ailp = lip - > li_ailp ;
2018-03-08 01:59:39 +03:00
spin_lock ( & ailp - > ail_lock ) ;
2018-01-25 00:38:49 +03:00
list_for_each_entry ( lip , & bp - > b_li_list , li_bio_list ) {
2017-08-09 04:21:50 +03:00
if ( lip - > li_ops - > iop_error )
lip - > li_ops - > iop_error ( lip , bp ) ;
}
2018-03-08 01:59:39 +03:00
spin_unlock ( & ailp - > ail_lock ) ;
2017-08-09 04:21:50 +03:00
}
2016-05-18 04:05:33 +03:00
static bool
xfs_buf_iodone_callback_error (
xfs: fix error handling for synchronous writes
If we get an IO error on a synchronous superblock write, we attach an
error release function to it so that when the last reference goes away
the release function is called and the buffer is invalidated and
unlocked. The buffer is left locked until the release function is
called so that other concurrent users of the buffer will be locked out
until the buffer error is fully processed.
Unfortunately, for the superblock buffer the filesyetm itself holds a
reference to the buffer which prevents the reference count from
dropping to zero and the release function being called. As a result,
once an IO error occurs on a sync write, the buffer will never be
unlocked and all future attempts to lock the buffer will hang.
To make matters worse, this problems is not unique to such buffers;
if there is a concurrent _xfs_buf_find() running, the lookup will grab
a reference to the buffer and then wait on the buffer lock, preventing
the reference count from ever falling to zero and hence unlocking the
buffer.
As such, the whole b_relse function implementation is broken because it
cannot rely on the buffer reference count falling to zero to unlock the
errored buffer. The synchronous write error path is the only path that
uses this callback - it is used to ensure that the synchronous waiter
gets the buffer error before the error state is cleared from the buffer
by the release function.
Given that the only sychronous buffer writes now go through xfs_bwrite
and the error path in question can only occur for a write of a dirty,
logged buffer, we can move most of the b_relse processing to happen
inline in xfs_buf_iodone_callbacks, just like a normal I/O completion.
In addition to that we make sure the error is not cleared in
xfs_buf_iodone_callbacks, so that xfs_bwrite can reliably check it.
Given that xfs_bwrite keeps the buffer locked until it has waited for
it and checked the error this allows to reliably propagate the error
to the caller, and make sure that the buffer is reliably unlocked.
Given that xfs_buf_iodone_callbacks was the only instance of the
b_relse callback we can remove it entirely.
Based on earlier patches by Dave Chinner and Ajeet Yadav.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Ajeet Yadav <ajeet.yadav.77@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
2011-01-07 16:02:23 +03:00
struct xfs_buf * bp )
2005-04-17 02:20:36 +04:00
{
2018-01-25 00:38:48 +03:00
struct xfs_buf_log_item * bip = bp - > b_log_item ;
2018-01-25 00:38:49 +03:00
struct xfs_log_item * lip ;
2018-01-25 00:38:48 +03:00
struct xfs_mount * mp ;
xfs: fix error handling for synchronous writes
If we get an IO error on a synchronous superblock write, we attach an
error release function to it so that when the last reference goes away
the release function is called and the buffer is invalidated and
unlocked. The buffer is left locked until the release function is
called so that other concurrent users of the buffer will be locked out
until the buffer error is fully processed.
Unfortunately, for the superblock buffer the filesyetm itself holds a
reference to the buffer which prevents the reference count from
dropping to zero and the release function being called. As a result,
once an IO error occurs on a sync write, the buffer will never be
unlocked and all future attempts to lock the buffer will hang.
To make matters worse, this problems is not unique to such buffers;
if there is a concurrent _xfs_buf_find() running, the lookup will grab
a reference to the buffer and then wait on the buffer lock, preventing
the reference count from ever falling to zero and hence unlocking the
buffer.
As such, the whole b_relse function implementation is broken because it
cannot rely on the buffer reference count falling to zero to unlock the
errored buffer. The synchronous write error path is the only path that
uses this callback - it is used to ensure that the synchronous waiter
gets the buffer error before the error state is cleared from the buffer
by the release function.
Given that the only sychronous buffer writes now go through xfs_bwrite
and the error path in question can only occur for a write of a dirty,
logged buffer, we can move most of the b_relse processing to happen
inline in xfs_buf_iodone_callbacks, just like a normal I/O completion.
In addition to that we make sure the error is not cleared in
xfs_buf_iodone_callbacks, so that xfs_bwrite can reliably check it.
Given that xfs_bwrite keeps the buffer locked until it has waited for
it and checked the error this allows to reliably propagate the error
to the caller, and make sure that the buffer is reliably unlocked.
Given that xfs_buf_iodone_callbacks was the only instance of the
b_relse callback we can remove it entirely.
Based on earlier patches by Dave Chinner and Ajeet Yadav.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Ajeet Yadav <ajeet.yadav.77@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
2011-01-07 16:02:23 +03:00
static ulong lasttime ;
static xfs_buftarg_t * lasttarg ;
2016-05-18 04:05:33 +03:00
struct xfs_error_cfg * cfg ;
2005-04-17 02:20:36 +04:00
2018-01-25 00:38:48 +03:00
/*
* The failed buffer might not have a buf_log_item attached or the
* log_item list might be empty . Get the mp from the available
* xfs_log_item
*/
2018-01-25 00:38:49 +03:00
lip = list_first_entry_or_null ( & bp - > b_li_list , struct xfs_log_item ,
li_bio_list ) ;
mp = lip ? lip - > li_mountp : bip - > bli_item . li_mountp ;
2018-01-25 00:38:48 +03:00
xfs: fix error handling for synchronous writes
If we get an IO error on a synchronous superblock write, we attach an
error release function to it so that when the last reference goes away
the release function is called and the buffer is invalidated and
unlocked. The buffer is left locked until the release function is
called so that other concurrent users of the buffer will be locked out
until the buffer error is fully processed.
Unfortunately, for the superblock buffer the filesyetm itself holds a
reference to the buffer which prevents the reference count from
dropping to zero and the release function being called. As a result,
once an IO error occurs on a sync write, the buffer will never be
unlocked and all future attempts to lock the buffer will hang.
To make matters worse, this problems is not unique to such buffers;
if there is a concurrent _xfs_buf_find() running, the lookup will grab
a reference to the buffer and then wait on the buffer lock, preventing
the reference count from ever falling to zero and hence unlocking the
buffer.
As such, the whole b_relse function implementation is broken because it
cannot rely on the buffer reference count falling to zero to unlock the
errored buffer. The synchronous write error path is the only path that
uses this callback - it is used to ensure that the synchronous waiter
gets the buffer error before the error state is cleared from the buffer
by the release function.
Given that the only sychronous buffer writes now go through xfs_bwrite
and the error path in question can only occur for a write of a dirty,
logged buffer, we can move most of the b_relse processing to happen
inline in xfs_buf_iodone_callbacks, just like a normal I/O completion.
In addition to that we make sure the error is not cleared in
xfs_buf_iodone_callbacks, so that xfs_bwrite can reliably check it.
Given that xfs_bwrite keeps the buffer locked until it has waited for
it and checked the error this allows to reliably propagate the error
to the caller, and make sure that the buffer is reliably unlocked.
Given that xfs_buf_iodone_callbacks was the only instance of the
b_relse callback we can remove it entirely.
Based on earlier patches by Dave Chinner and Ajeet Yadav.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Ajeet Yadav <ajeet.yadav.77@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
2011-01-07 16:02:23 +03:00
/*
* If we ' ve already decided to shutdown the filesystem because of
* I / O errors , there ' s no point in giving this a retry .
*/
2016-05-18 04:05:33 +03:00
if ( XFS_FORCED_SHUTDOWN ( mp ) )
goto out_stale ;
2005-04-17 02:20:36 +04:00
2011-07-23 03:40:40 +04:00
if ( bp - > b_target ! = lasttarg | |
xfs: fix error handling for synchronous writes
If we get an IO error on a synchronous superblock write, we attach an
error release function to it so that when the last reference goes away
the release function is called and the buffer is invalidated and
unlocked. The buffer is left locked until the release function is
called so that other concurrent users of the buffer will be locked out
until the buffer error is fully processed.
Unfortunately, for the superblock buffer the filesyetm itself holds a
reference to the buffer which prevents the reference count from
dropping to zero and the release function being called. As a result,
once an IO error occurs on a sync write, the buffer will never be
unlocked and all future attempts to lock the buffer will hang.
To make matters worse, this problems is not unique to such buffers;
if there is a concurrent _xfs_buf_find() running, the lookup will grab
a reference to the buffer and then wait on the buffer lock, preventing
the reference count from ever falling to zero and hence unlocking the
buffer.
As such, the whole b_relse function implementation is broken because it
cannot rely on the buffer reference count falling to zero to unlock the
errored buffer. The synchronous write error path is the only path that
uses this callback - it is used to ensure that the synchronous waiter
gets the buffer error before the error state is cleared from the buffer
by the release function.
Given that the only sychronous buffer writes now go through xfs_bwrite
and the error path in question can only occur for a write of a dirty,
logged buffer, we can move most of the b_relse processing to happen
inline in xfs_buf_iodone_callbacks, just like a normal I/O completion.
In addition to that we make sure the error is not cleared in
xfs_buf_iodone_callbacks, so that xfs_bwrite can reliably check it.
Given that xfs_bwrite keeps the buffer locked until it has waited for
it and checked the error this allows to reliably propagate the error
to the caller, and make sure that the buffer is reliably unlocked.
Given that xfs_buf_iodone_callbacks was the only instance of the
b_relse callback we can remove it entirely.
Based on earlier patches by Dave Chinner and Ajeet Yadav.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Ajeet Yadav <ajeet.yadav.77@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
2011-01-07 16:02:23 +03:00
time_after ( jiffies , ( lasttime + 5 * HZ ) ) ) {
lasttime = jiffies ;
2020-01-24 04:01:20 +03:00
xfs_buf_ioerror_alert ( bp , __this_address ) ;
xfs: fix error handling for synchronous writes
If we get an IO error on a synchronous superblock write, we attach an
error release function to it so that when the last reference goes away
the release function is called and the buffer is invalidated and
unlocked. The buffer is left locked until the release function is
called so that other concurrent users of the buffer will be locked out
until the buffer error is fully processed.
Unfortunately, for the superblock buffer the filesyetm itself holds a
reference to the buffer which prevents the reference count from
dropping to zero and the release function being called. As a result,
once an IO error occurs on a sync write, the buffer will never be
unlocked and all future attempts to lock the buffer will hang.
To make matters worse, this problems is not unique to such buffers;
if there is a concurrent _xfs_buf_find() running, the lookup will grab
a reference to the buffer and then wait on the buffer lock, preventing
the reference count from ever falling to zero and hence unlocking the
buffer.
As such, the whole b_relse function implementation is broken because it
cannot rely on the buffer reference count falling to zero to unlock the
errored buffer. The synchronous write error path is the only path that
uses this callback - it is used to ensure that the synchronous waiter
gets the buffer error before the error state is cleared from the buffer
by the release function.
Given that the only sychronous buffer writes now go through xfs_bwrite
and the error path in question can only occur for a write of a dirty,
logged buffer, we can move most of the b_relse processing to happen
inline in xfs_buf_iodone_callbacks, just like a normal I/O completion.
In addition to that we make sure the error is not cleared in
xfs_buf_iodone_callbacks, so that xfs_bwrite can reliably check it.
Given that xfs_bwrite keeps the buffer locked until it has waited for
it and checked the error this allows to reliably propagate the error
to the caller, and make sure that the buffer is reliably unlocked.
Given that xfs_buf_iodone_callbacks was the only instance of the
b_relse callback we can remove it entirely.
Based on earlier patches by Dave Chinner and Ajeet Yadav.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Ajeet Yadav <ajeet.yadav.77@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
2011-01-07 16:02:23 +03:00
}
2011-07-23 03:40:40 +04:00
lasttarg = bp - > b_target ;
2005-04-17 02:20:36 +04:00
2016-05-18 04:05:33 +03:00
/* synchronous writes will have callers process the error */
if ( ! ( bp - > b_flags & XBF_ASYNC ) )
goto out_stale ;
trace_xfs_buf_item_iodone_async ( bp , _RET_IP_ ) ;
ASSERT ( bp - > b_iodone ! = NULL ) ;
2016-07-20 03:54:09 +03:00
cfg = xfs_error_get_cfg ( mp , XFS_ERR_METADATA , bp - > b_error ) ;
xfs: fix error handling for synchronous writes
If we get an IO error on a synchronous superblock write, we attach an
error release function to it so that when the last reference goes away
the release function is called and the buffer is invalidated and
unlocked. The buffer is left locked until the release function is
called so that other concurrent users of the buffer will be locked out
until the buffer error is fully processed.
Unfortunately, for the superblock buffer the filesyetm itself holds a
reference to the buffer which prevents the reference count from
dropping to zero and the release function being called. As a result,
once an IO error occurs on a sync write, the buffer will never be
unlocked and all future attempts to lock the buffer will hang.
To make matters worse, this problems is not unique to such buffers;
if there is a concurrent _xfs_buf_find() running, the lookup will grab
a reference to the buffer and then wait on the buffer lock, preventing
the reference count from ever falling to zero and hence unlocking the
buffer.
As such, the whole b_relse function implementation is broken because it
cannot rely on the buffer reference count falling to zero to unlock the
errored buffer. The synchronous write error path is the only path that
uses this callback - it is used to ensure that the synchronous waiter
gets the buffer error before the error state is cleared from the buffer
by the release function.
Given that the only sychronous buffer writes now go through xfs_bwrite
and the error path in question can only occur for a write of a dirty,
logged buffer, we can move most of the b_relse processing to happen
inline in xfs_buf_iodone_callbacks, just like a normal I/O completion.
In addition to that we make sure the error is not cleared in
xfs_buf_iodone_callbacks, so that xfs_bwrite can reliably check it.
Given that xfs_bwrite keeps the buffer locked until it has waited for
it and checked the error this allows to reliably propagate the error
to the caller, and make sure that the buffer is reliably unlocked.
Given that xfs_buf_iodone_callbacks was the only instance of the
b_relse callback we can remove it entirely.
Based on earlier patches by Dave Chinner and Ajeet Yadav.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Ajeet Yadav <ajeet.yadav.77@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
2011-01-07 16:02:23 +03:00
/*
2011-03-31 05:57:33 +04:00
* If the write was asynchronous then no one will be looking for the
2016-05-18 04:05:33 +03:00
* error . If this is the first failure of this type , clear the error
* state and write the buffer out again . This means we always retry an
* async write failure at least once , but we also need to set the buffer
* up to behave correctly now for repeated failures .
xfs: fix error handling for synchronous writes
If we get an IO error on a synchronous superblock write, we attach an
error release function to it so that when the last reference goes away
the release function is called and the buffer is invalidated and
unlocked. The buffer is left locked until the release function is
called so that other concurrent users of the buffer will be locked out
until the buffer error is fully processed.
Unfortunately, for the superblock buffer the filesyetm itself holds a
reference to the buffer which prevents the reference count from
dropping to zero and the release function being called. As a result,
once an IO error occurs on a sync write, the buffer will never be
unlocked and all future attempts to lock the buffer will hang.
To make matters worse, this problems is not unique to such buffers;
if there is a concurrent _xfs_buf_find() running, the lookup will grab
a reference to the buffer and then wait on the buffer lock, preventing
the reference count from ever falling to zero and hence unlocking the
buffer.
As such, the whole b_relse function implementation is broken because it
cannot rely on the buffer reference count falling to zero to unlock the
errored buffer. The synchronous write error path is the only path that
uses this callback - it is used to ensure that the synchronous waiter
gets the buffer error before the error state is cleared from the buffer
by the release function.
Given that the only sychronous buffer writes now go through xfs_bwrite
and the error path in question can only occur for a write of a dirty,
logged buffer, we can move most of the b_relse processing to happen
inline in xfs_buf_iodone_callbacks, just like a normal I/O completion.
In addition to that we make sure the error is not cleared in
xfs_buf_iodone_callbacks, so that xfs_bwrite can reliably check it.
Given that xfs_bwrite keeps the buffer locked until it has waited for
it and checked the error this allows to reliably propagate the error
to the caller, and make sure that the buffer is reliably unlocked.
Given that xfs_buf_iodone_callbacks was the only instance of the
b_relse callback we can remove it entirely.
Based on earlier patches by Dave Chinner and Ajeet Yadav.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Ajeet Yadav <ajeet.yadav.77@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
2011-01-07 16:02:23 +03:00
*/
2016-07-20 03:53:22 +03:00
if ( ! ( bp - > b_flags & ( XBF_STALE | XBF_WRITE_FAIL ) ) | |
2016-05-18 04:05:33 +03:00
bp - > b_last_error ! = bp - > b_error ) {
2016-07-20 03:53:22 +03:00
bp - > b_flags | = ( XBF_WRITE | XBF_DONE | XBF_WRITE_FAIL ) ;
2016-05-18 04:05:33 +03:00
bp - > b_last_error = bp - > b_error ;
2016-09-14 00:51:30 +03:00
if ( cfg - > retry_timeout ! = XFS_ERR_RETRY_FOREVER & &
! bp - > b_first_retry_time )
2016-07-20 03:54:09 +03:00
bp - > b_first_retry_time = jiffies ;
2016-05-18 04:08:15 +03:00
2016-05-18 04:05:33 +03:00
xfs_buf_ioerror ( bp , 0 ) ;
xfs_buf_submit ( bp ) ;
return true ;
}
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +04:00
2016-05-18 04:05:33 +03:00
/*
* Repeated failure on an async write . Take action according to the
* error configuration we have been set up to use .
*/
2016-05-18 04:08:15 +03:00
if ( cfg - > max_retries ! = XFS_ERR_RETRY_FOREVER & &
+ + bp - > b_retries > cfg - > max_retries )
goto permanent_error ;
2016-09-14 00:51:30 +03:00
if ( cfg - > retry_timeout ! = XFS_ERR_RETRY_FOREVER & &
2016-05-18 04:08:15 +03:00
time_after ( jiffies , cfg - > retry_timeout + bp - > b_first_retry_time ) )
goto permanent_error ;
xfs: fix error handling for synchronous writes
If we get an IO error on a synchronous superblock write, we attach an
error release function to it so that when the last reference goes away
the release function is called and the buffer is invalidated and
unlocked. The buffer is left locked until the release function is
called so that other concurrent users of the buffer will be locked out
until the buffer error is fully processed.
Unfortunately, for the superblock buffer the filesyetm itself holds a
reference to the buffer which prevents the reference count from
dropping to zero and the release function being called. As a result,
once an IO error occurs on a sync write, the buffer will never be
unlocked and all future attempts to lock the buffer will hang.
To make matters worse, this problems is not unique to such buffers;
if there is a concurrent _xfs_buf_find() running, the lookup will grab
a reference to the buffer and then wait on the buffer lock, preventing
the reference count from ever falling to zero and hence unlocking the
buffer.
As such, the whole b_relse function implementation is broken because it
cannot rely on the buffer reference count falling to zero to unlock the
errored buffer. The synchronous write error path is the only path that
uses this callback - it is used to ensure that the synchronous waiter
gets the buffer error before the error state is cleared from the buffer
by the release function.
Given that the only sychronous buffer writes now go through xfs_bwrite
and the error path in question can only occur for a write of a dirty,
logged buffer, we can move most of the b_relse processing to happen
inline in xfs_buf_iodone_callbacks, just like a normal I/O completion.
In addition to that we make sure the error is not cleared in
xfs_buf_iodone_callbacks, so that xfs_bwrite can reliably check it.
Given that xfs_bwrite keeps the buffer locked until it has waited for
it and checked the error this allows to reliably propagate the error
to the caller, and make sure that the buffer is reliably unlocked.
Given that xfs_buf_iodone_callbacks was the only instance of the
b_relse callback we can remove it entirely.
Based on earlier patches by Dave Chinner and Ajeet Yadav.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Ajeet Yadav <ajeet.yadav.77@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
2011-01-07 16:02:23 +03:00
2016-05-18 04:11:27 +03:00
/* At unmount we may treat errors differently */
if ( ( mp - > m_flags & XFS_MOUNT_UNMOUNTING ) & & mp - > m_fail_unmount )
goto permanent_error ;
2017-08-09 04:21:50 +03:00
/*
* Still a transient error , run IO completion failure callbacks and let
* the higher layers retry the buffer .
*/
xfs_buf_do_callbacks_fail ( bp ) ;
2016-05-18 04:05:33 +03:00
xfs_buf_ioerror ( bp , 0 ) ;
xfs_buf_relse ( bp ) ;
return true ;
2009-12-15 02:14:59 +03:00
xfs: fix error handling for synchronous writes
If we get an IO error on a synchronous superblock write, we attach an
error release function to it so that when the last reference goes away
the release function is called and the buffer is invalidated and
unlocked. The buffer is left locked until the release function is
called so that other concurrent users of the buffer will be locked out
until the buffer error is fully processed.
Unfortunately, for the superblock buffer the filesyetm itself holds a
reference to the buffer which prevents the reference count from
dropping to zero and the release function being called. As a result,
once an IO error occurs on a sync write, the buffer will never be
unlocked and all future attempts to lock the buffer will hang.
To make matters worse, this problems is not unique to such buffers;
if there is a concurrent _xfs_buf_find() running, the lookup will grab
a reference to the buffer and then wait on the buffer lock, preventing
the reference count from ever falling to zero and hence unlocking the
buffer.
As such, the whole b_relse function implementation is broken because it
cannot rely on the buffer reference count falling to zero to unlock the
errored buffer. The synchronous write error path is the only path that
uses this callback - it is used to ensure that the synchronous waiter
gets the buffer error before the error state is cleared from the buffer
by the release function.
Given that the only sychronous buffer writes now go through xfs_bwrite
and the error path in question can only occur for a write of a dirty,
logged buffer, we can move most of the b_relse processing to happen
inline in xfs_buf_iodone_callbacks, just like a normal I/O completion.
In addition to that we make sure the error is not cleared in
xfs_buf_iodone_callbacks, so that xfs_bwrite can reliably check it.
Given that xfs_bwrite keeps the buffer locked until it has waited for
it and checked the error this allows to reliably propagate the error
to the caller, and make sure that the buffer is reliably unlocked.
Given that xfs_buf_iodone_callbacks was the only instance of the
b_relse callback we can remove it entirely.
Based on earlier patches by Dave Chinner and Ajeet Yadav.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Ajeet Yadav <ajeet.yadav.77@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
2011-01-07 16:02:23 +03:00
/*
2016-05-18 04:05:33 +03:00
* Permanent error - we need to trigger a shutdown if we haven ' t already
* to indicate that inconsistency will result from this action .
xfs: fix error handling for synchronous writes
If we get an IO error on a synchronous superblock write, we attach an
error release function to it so that when the last reference goes away
the release function is called and the buffer is invalidated and
unlocked. The buffer is left locked until the release function is
called so that other concurrent users of the buffer will be locked out
until the buffer error is fully processed.
Unfortunately, for the superblock buffer the filesyetm itself holds a
reference to the buffer which prevents the reference count from
dropping to zero and the release function being called. As a result,
once an IO error occurs on a sync write, the buffer will never be
unlocked and all future attempts to lock the buffer will hang.
To make matters worse, this problems is not unique to such buffers;
if there is a concurrent _xfs_buf_find() running, the lookup will grab
a reference to the buffer and then wait on the buffer lock, preventing
the reference count from ever falling to zero and hence unlocking the
buffer.
As such, the whole b_relse function implementation is broken because it
cannot rely on the buffer reference count falling to zero to unlock the
errored buffer. The synchronous write error path is the only path that
uses this callback - it is used to ensure that the synchronous waiter
gets the buffer error before the error state is cleared from the buffer
by the release function.
Given that the only sychronous buffer writes now go through xfs_bwrite
and the error path in question can only occur for a write of a dirty,
logged buffer, we can move most of the b_relse processing to happen
inline in xfs_buf_iodone_callbacks, just like a normal I/O completion.
In addition to that we make sure the error is not cleared in
xfs_buf_iodone_callbacks, so that xfs_bwrite can reliably check it.
Given that xfs_bwrite keeps the buffer locked until it has waited for
it and checked the error this allows to reliably propagate the error
to the caller, and make sure that the buffer is reliably unlocked.
Given that xfs_buf_iodone_callbacks was the only instance of the
b_relse callback we can remove it entirely.
Based on earlier patches by Dave Chinner and Ajeet Yadav.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Ajeet Yadav <ajeet.yadav.77@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
2011-01-07 16:02:23 +03:00
*/
2016-05-18 04:05:33 +03:00
permanent_error :
xfs_force_shutdown ( mp , SHUTDOWN_META_IO_ERROR ) ;
out_stale :
2011-10-10 20:52:46 +04:00
xfs_buf_stale ( bp ) ;
2016-02-10 07:01:11 +03:00
bp - > b_flags | = XBF_DONE ;
2009-12-15 02:14:59 +03:00
trace_xfs_buf_error_relse ( bp , _RET_IP_ ) ;
2016-05-18 04:05:33 +03:00
return false ;
}
/*
* This is the iodone ( ) function for buffers which have had callbacks attached
* to them by xfs_buf_attach_iodone ( ) . We need to iterate the items on the
* callback list , mark the buffer as having no more callbacks and then push the
* buffer through IO completion processing .
*/
void
xfs_buf_iodone_callbacks (
struct xfs_buf * bp )
{
/*
* If there is an error , process it . Some errors require us
* to run callbacks after failure processing is done so we
* detect that and take appropriate action .
*/
if ( bp - > b_error & & xfs_buf_iodone_callback_error ( bp ) )
return ;
/*
* Successful IO or permanent error . Either way , we can clear the
* retry state here in preparation for the next error that may occur .
*/
bp - > b_last_error = 0 ;
2016-05-18 04:08:15 +03:00
bp - > b_retries = 0 ;
2017-02-04 01:39:07 +03:00
bp - > b_first_retry_time = 0 ;
2009-12-15 02:14:59 +03:00
2010-12-03 09:00:52 +03:00
xfs_buf_do_callbacks ( bp ) ;
2018-01-25 00:38:48 +03:00
bp - > b_log_item = NULL ;
2018-01-25 00:38:49 +03:00
list_del_init ( & bp - > b_li_list ) ;
2011-07-13 15:43:49 +04:00
bp - > b_iodone = NULL ;
2014-10-02 03:04:22 +04:00
xfs_buf_ioend ( bp ) ;
2005-04-17 02:20:36 +04:00
}
/*
* This is the iodone ( ) function for buffers which have been
* logged . It is called when they are eventually flushed out .
* It should remove the buf item from the AIL , and free the buf item .
* It is called by xfs_buf_iodone_callbacks ( ) above which will take
* care of cleaning up the buffer itself .
*/
void
xfs_buf_iodone (
2010-06-23 12:11:15 +04:00
struct xfs_buf * bp ,
struct xfs_log_item * lip )
2005-04-17 02:20:36 +04:00
{
2010-06-23 12:11:15 +04:00
struct xfs_ail * ailp = lip - > li_ailp ;
2005-04-17 02:20:36 +04:00
2010-06-23 12:11:15 +04:00
ASSERT ( BUF_ITEM ( lip ) - > bli_buf = = bp ) ;
2005-04-17 02:20:36 +04:00
2008-09-17 10:52:13 +04:00
xfs_buf_rele ( bp ) ;
2005-04-17 02:20:36 +04:00
/*
* If we are forcibly shutting down , this may well be
* off the AIL already . That ' s because we simulate the
* log - committed callbacks to unpin these buffers . Or we may never
* have put this item on AIL because of the transaction was
2008-10-30 09:39:58 +03:00
* aborted forcibly . xfs_trans_ail_delete ( ) takes care of these .
2005-04-17 02:20:36 +04:00
*
* Either way , AIL is useless if we ' re forcing a shutdown .
*/
2018-03-08 01:59:39 +03:00
spin_lock ( & ailp - > ail_lock ) ;
2012-04-23 09:58:41 +04:00
xfs_trans_ail_delete ( ailp , lip , SHUTDOWN_CORRUPT_INCORE ) ;
2010-06-23 12:11:15 +04:00
xfs_buf_item_free ( BUF_ITEM ( lip ) ) ;
2005-04-17 02:20:36 +04:00
}
xfs: Properly retry failed inode items in case of error during buffer writeback
When a buffer has been failed during writeback, the inode items into it
are kept flush locked, and are never resubmitted due the flush lock, so,
if any buffer fails to be written, the items in AIL are never written to
disk and never unlocked.
This causes unmount operation to hang due these items flush locked in AIL,
but this also causes the items in AIL to never be written back, even when
the IO device comes back to normal.
I've been testing this patch with a DM-thin device, creating a
filesystem larger than the real device.
When writing enough data to fill the DM-thin device, XFS receives ENOSPC
errors from the device, and keep spinning on xfsaild (when 'retry
forever' configuration is set).
At this point, the filesystem can not be unmounted because of the flush locked
items in AIL, but worse, the items in AIL are never retried at all
(once xfs_inode_item_push() will skip the items that are flush locked),
even if the underlying DM-thin device is expanded to the proper size.
This patch fixes both cases, retrying any item that has been failed
previously, using the infra-structure provided by the previous patch.
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
2017-08-09 04:21:50 +03:00
/*
2018-11-20 00:31:08 +03:00
* Requeue a failed buffer for writeback .
xfs: Properly retry failed inode items in case of error during buffer writeback
When a buffer has been failed during writeback, the inode items into it
are kept flush locked, and are never resubmitted due the flush lock, so,
if any buffer fails to be written, the items in AIL are never written to
disk and never unlocked.
This causes unmount operation to hang due these items flush locked in AIL,
but this also causes the items in AIL to never be written back, even when
the IO device comes back to normal.
I've been testing this patch with a DM-thin device, creating a
filesystem larger than the real device.
When writing enough data to fill the DM-thin device, XFS receives ENOSPC
errors from the device, and keep spinning on xfsaild (when 'retry
forever' configuration is set).
At this point, the filesystem can not be unmounted because of the flush locked
items in AIL, but worse, the items in AIL are never retried at all
(once xfs_inode_item_push() will skip the items that are flush locked),
even if the underlying DM-thin device is expanded to the proper size.
This patch fixes both cases, retrying any item that has been failed
previously, using the infra-structure provided by the previous patch.
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
2017-08-09 04:21:50 +03:00
*
2018-11-20 00:31:08 +03:00
* We clear the log item failed state here as well , but we have to be careful
* about reference counts because the only active reference counts on the buffer
* may be the failed log items . Hence if we clear the log item failed state
* before queuing the buffer for IO we can release all active references to
* the buffer and free it , leading to use after free problems in
* xfs_buf_delwri_queue . It makes no difference to the buffer or log items which
* order we process them in - the buffer is locked , and we own the buffer list
* so nothing on them is going to change while we are performing this action .
*
* Hence we can safely queue the buffer for IO before we clear the failed log
* item state , therefore always having an active reference to the buffer and
* avoiding the transient zero - reference state that leads to use - after - free .
*
* Return true if the buffer was added to the buffer list , false if it was
* already on the buffer list .
xfs: Properly retry failed inode items in case of error during buffer writeback
When a buffer has been failed during writeback, the inode items into it
are kept flush locked, and are never resubmitted due the flush lock, so,
if any buffer fails to be written, the items in AIL are never written to
disk and never unlocked.
This causes unmount operation to hang due these items flush locked in AIL,
but this also causes the items in AIL to never be written back, even when
the IO device comes back to normal.
I've been testing this patch with a DM-thin device, creating a
filesystem larger than the real device.
When writing enough data to fill the DM-thin device, XFS receives ENOSPC
errors from the device, and keep spinning on xfsaild (when 'retry
forever' configuration is set).
At this point, the filesystem can not be unmounted because of the flush locked
items in AIL, but worse, the items in AIL are never retried at all
(once xfs_inode_item_push() will skip the items that are flush locked),
even if the underlying DM-thin device is expanded to the proper size.
This patch fixes both cases, retrying any item that has been failed
previously, using the infra-structure provided by the previous patch.
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
2017-08-09 04:21:50 +03:00
*/
bool
xfs_buf_resubmit_failed_buffers (
struct xfs_buf * bp ,
struct list_head * buffer_list )
{
2018-01-25 00:38:49 +03:00
struct xfs_log_item * lip ;
2018-11-20 00:31:08 +03:00
bool ret ;
ret = xfs_buf_delwri_queue ( bp , buffer_list ) ;
xfs: Properly retry failed inode items in case of error during buffer writeback
When a buffer has been failed during writeback, the inode items into it
are kept flush locked, and are never resubmitted due the flush lock, so,
if any buffer fails to be written, the items in AIL are never written to
disk and never unlocked.
This causes unmount operation to hang due these items flush locked in AIL,
but this also causes the items in AIL to never be written back, even when
the IO device comes back to normal.
I've been testing this patch with a DM-thin device, creating a
filesystem larger than the real device.
When writing enough data to fill the DM-thin device, XFS receives ENOSPC
errors from the device, and keep spinning on xfsaild (when 'retry
forever' configuration is set).
At this point, the filesystem can not be unmounted because of the flush locked
items in AIL, but worse, the items in AIL are never retried at all
(once xfs_inode_item_push() will skip the items that are flush locked),
even if the underlying DM-thin device is expanded to the proper size.
This patch fixes both cases, retrying any item that has been failed
previously, using the infra-structure provided by the previous patch.
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
2017-08-09 04:21:50 +03:00
/*
2018-11-20 00:31:08 +03:00
* XFS_LI_FAILED set / clear is protected by ail_lock , caller of this
xfs: Properly retry failed inode items in case of error during buffer writeback
When a buffer has been failed during writeback, the inode items into it
are kept flush locked, and are never resubmitted due the flush lock, so,
if any buffer fails to be written, the items in AIL are never written to
disk and never unlocked.
This causes unmount operation to hang due these items flush locked in AIL,
but this also causes the items in AIL to never be written back, even when
the IO device comes back to normal.
I've been testing this patch with a DM-thin device, creating a
filesystem larger than the real device.
When writing enough data to fill the DM-thin device, XFS receives ENOSPC
errors from the device, and keep spinning on xfsaild (when 'retry
forever' configuration is set).
At this point, the filesystem can not be unmounted because of the flush locked
items in AIL, but worse, the items in AIL are never retried at all
(once xfs_inode_item_push() will skip the items that are flush locked),
even if the underlying DM-thin device is expanded to the proper size.
This patch fixes both cases, retrying any item that has been failed
previously, using the infra-structure provided by the previous patch.
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
2017-08-09 04:21:50 +03:00
* function already have it acquired
*/
2018-01-25 00:38:49 +03:00
list_for_each_entry ( lip , & bp - > b_li_list , li_bio_list )
xfs: Properly retry failed inode items in case of error during buffer writeback
When a buffer has been failed during writeback, the inode items into it
are kept flush locked, and are never resubmitted due the flush lock, so,
if any buffer fails to be written, the items in AIL are never written to
disk and never unlocked.
This causes unmount operation to hang due these items flush locked in AIL,
but this also causes the items in AIL to never be written back, even when
the IO device comes back to normal.
I've been testing this patch with a DM-thin device, creating a
filesystem larger than the real device.
When writing enough data to fill the DM-thin device, XFS receives ENOSPC
errors from the device, and keep spinning on xfsaild (when 'retry
forever' configuration is set).
At this point, the filesystem can not be unmounted because of the flush locked
items in AIL, but worse, the items in AIL are never retried at all
(once xfs_inode_item_push() will skip the items that are flush locked),
even if the underlying DM-thin device is expanded to the proper size.
This patch fixes both cases, retrying any item that has been failed
previously, using the infra-structure provided by the previous patch.
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
2017-08-09 04:21:50 +03:00
xfs_clear_li_failed ( lip ) ;
2018-11-20 00:31:08 +03:00
return ret ;
xfs: Properly retry failed inode items in case of error during buffer writeback
When a buffer has been failed during writeback, the inode items into it
are kept flush locked, and are never resubmitted due the flush lock, so,
if any buffer fails to be written, the items in AIL are never written to
disk and never unlocked.
This causes unmount operation to hang due these items flush locked in AIL,
but this also causes the items in AIL to never be written back, even when
the IO device comes back to normal.
I've been testing this patch with a DM-thin device, creating a
filesystem larger than the real device.
When writing enough data to fill the DM-thin device, XFS receives ENOSPC
errors from the device, and keep spinning on xfsaild (when 'retry
forever' configuration is set).
At this point, the filesystem can not be unmounted because of the flush locked
items in AIL, but worse, the items in AIL are never retried at all
(once xfs_inode_item_push() will skip the items that are flush locked),
even if the underlying DM-thin device is expanded to the proper size.
This patch fixes both cases, retrying any item that has been failed
previously, using the infra-structure provided by the previous patch.
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
2017-08-09 04:21:50 +03:00
}