71bddbccab
While running a new fstest that races a readonly remount with scrub running in repair mode, I observed the kernel tripping over debugging assertions in the log quiesce code that were checking that the CIL was empty. When the sysadmin runs scrub in repair mode, the scrub code allocates real transactions (with reservations) to change things, but doesn't increment the superblock writers count to block a readonly remount attempt while it is running. We don't require the userspace caller to have a writable file descriptor to run repairs, so we have to call mnt_want_write_file to obtain freeze protection and increment the writers count. It's ok to remove the call to sb_start_write for the dry-run case because commit 8321ddb2fa29 removed the behavior where scrub and fsfreeze fight over the buffer LRU. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Chandan Babu R <chandanrlinux@gmail.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
16 lines
425 B
C
16 lines
425 B
C
// SPDX-License-Identifier: GPL-2.0+
|
|
/*
|
|
* Copyright (C) 2017 Oracle. All Rights Reserved.
|
|
* Author: Darrick J. Wong <darrick.wong@oracle.com>
|
|
*/
|
|
#ifndef __XFS_SCRUB_H__
|
|
#define __XFS_SCRUB_H__
|
|
|
|
#ifndef CONFIG_XFS_ONLINE_SCRUB
|
|
# define xfs_scrub_metadata(file, sm) (-ENOTTY)
|
|
#else
|
|
int xfs_scrub_metadata(struct file *file, struct xfs_scrub_metadata *sm);
|
|
#endif /* CONFIG_XFS_ONLINE_SCRUB */
|
|
|
|
#endif /* __XFS_SCRUB_H__ */
|