I have been working in a bug still regarding xfs fail_at_unmount configuration,
where, even though the configuration is enable, an unmount attempt will still
hang if the AIL buf items are locked as a result of a previous failed attempt to
flush these items.
Currently, if there is a failure while trying to flush inode buffers to disk,
these items are kept in AIL with FLUSHING status and with the locks held, making
them unable to be retried. Either during unmount, where they will be retried and
'failed', or if using a thin provisioned device, the pool is actually extended, to
accomodate these not-yet-flushed items, instead of retrying to flush such items,
xfs is unable to retry them, once they are already locked.
Brian came with a suggestion about how to fix it, releasing the locks in case we
had a failed write attempt.
I know there are some other persons also involved in this problem, so I think
it's a good idea to send Brian's patch here and get some more comments about it.
I'm keeping Brian's signed-off once he wrote the whole patch.
Signed-off-by: Brian Foster <bfoster@xxxxxxxxxx>
Signed-off-by: Carlos Maiolino <cmaiolino@xxxxxxxxxx>
---
fs/xfs/xfs_inode_item.c | 21 ++++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/fs/xfs/xfs_inode_item.c b/fs/xfs/xfs_inode_item.c
index 892c2ac..cce0373 100644
--- a/fs/xfs/xfs_inode_item.c
+++ b/fs/xfs/xfs_inode_item.c
@@ -517,7 +517,26 @@ xfs_inode_item_push(
* the AIL.
*/
if (!xfs_iflock_nowait(ip)) {
- rval = XFS_ITEM_FLUSHING;
+ int error;
+ struct xfs_dinode *dip;
+
+ error = xfs_imap_to_bp(ip->i_mount, NULL, &ip->i_imap, &dip,
+ &bp, XBF_TRYLOCK, 0);
+ if (error) {
+ rval = XFS_ITEM_FLUSHING;
+ goto out_unlock;
+ }
+
+ if (!(bp->b_flags & XBF_WRITE_FAIL)) {
+ rval = XFS_ITEM_FLUSHING;
+ xfs_buf_relse(bp);
+ goto out_unlock;
+ }
+
+ if (!xfs_buf_delwri_queue(bp, buffer_list))
+ rval = XFS_ITEM_FLUSHING;
+
+ xfs_buf_relse(bp);
goto out_unlock;
}
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
