xfs: mark all internal workqueues as freezable
PATCH 1/1 xfs: mark all internal workqueues as freezable
Workqueues must be explicitly set as freezable to ensure they are frozen in the assocated part of the hibernation/suspend sequence. Freezing of workqueues and kernel threads is important to ensure that modifications are not made on-disk after the hibernation image has been created. Otherwise, the in-memory state can become inconsistent with what is on disk and eventually lead to filesystem corruption. We have reports of free space btree corruptions that occur immediately after restore from hibernate that suggest the xfs-eofblocks workqueue could be causing such problems if it races with hibernation.
Mark all of the internal XFS workqueues as freezable to ensure nothing changes on-disk once the freezer infrastructure freezes kernel threads and creates the hibernation image.
---
Hi all,
Unfortunately I still haven't been able to reproduce the specific corruption. The best I've been able to do is reproduce a hang/crash on hibernate if I coordinate hibernate with background eofblocks scans, but I couldn't get any output as to what was going on. I ran some similar test cycles with this change and didn't reproduce that hang, so this appears to be effective at least.
I reproduce other such problems running hibernation while doing stress level I/O, so to be honest I'm not sure how trustworthy/reliable hibernate is in general. This appears like the right thing to do to reduce chances of corruptions in any event.
Brian
fs/xfs/xfs_buf.c | 2 +- fs/xfs/xfs_mru_cache.c | 3 ++- fs/xfs/xfs_super.c | 15 ++++++++------- 3 files changed, 11 insertions(+), 9 deletions(-)
fs/xfs/xfs_buf.c +1 -1
@@ -1884,7 +1884,7 @@ xfs_buf_init(void) goto out; xfslogd_workqueue =alloc_workqueue ("xfslogd" , -WQ_MEM_RECLAIM |WQ_HIGHPRI ,1 ); +WQ_MEM_RECLAIM |WQ_HIGHPRI |WQ_FREEZABLE ,1 );if (!xfslogd_workqueue) goto out_free_buf_zone;
fs/xfs/xfs_mru_cache.c +2 -1
@@ -304,7 +304,8 @@ _xfs_mru_cache_reap(int xfs_mru_cache_init (void ) { - xfs_mru_reap_wq =alloc_workqueue ("xfs_mru_cache" ,WQ_MEM_RECLAIM ,1 ); + xfs_mru_reap_wq =alloc_workqueue ("xfs_mru_cache" , +WQ_MEM_RECLAIM |WQ_FREEZABLE ,1 );if (!xfs_mru_reap_wq)return -ENOMEM ;return 0 ;
fs/xfs/xfs_super.c +8 -7
@@ -838,32 +838,32 @@ xfs_init_mount_workqueues( struct xfs_mount *mp) { mp->m_data_workqueue =alloc_workqueue ("xfs-data/%s" , -WQ_MEM_RECLAIM ,0 , mp->m_fsname); +WQ_MEM_RECLAIM |WQ_FREEZABLE ,0 , mp->m_fsname);if (!mp->m_data_workqueue) goto out; mp->m_unwritten_workqueue =alloc_workqueue ("xfs-conv/%s" , -WQ_MEM_RECLAIM ,0 , mp->m_fsname); +WQ_MEM_RECLAIM |WQ_FREEZABLE ,0 , mp->m_fsname);if (!mp->m_unwritten_workqueue) goto out_destroy_data_iodone_queue; mp->m_cil_workqueue =alloc_workqueue ("xfs-cil/%s" , -WQ_MEM_RECLAIM ,0 , mp->m_fsname); +WQ_MEM_RECLAIM |WQ_FREEZABLE ,0 , mp->m_fsname);if (!mp->m_cil_workqueue) goto out_destroy_unwritten; mp->m_reclaim_workqueue =alloc_workqueue ("xfs-reclaim/%s" , -0 ,0 , mp->m_fsname); +WQ_FREEZABLE ,0 , mp->m_fsname);if (!mp->m_reclaim_workqueue) goto out_destroy_cil; mp->m_log_workqueue =alloc_workqueue ("xfs-log/%s" , -0 ,0 , mp->m_fsname); +WQ_FREEZABLE ,0 , mp->m_fsname);if (!mp->m_log_workqueue) goto out_destroy_reclaim; mp->m_eofblocks_workqueue =alloc_workqueue ("xfs-eofblocks/%s" , -0 ,0 , mp->m_fsname); +WQ_FREEZABLE ,0 , mp->m_fsname);if (!mp->m_eofblocks_workqueue) goto out_destroy_log;
@@ -1715,7 +1715,8 @@ xfs_init_workqueues(void)* AGs in all the filesystems mounted. Hence use the default large * max_active value for this workqueue. */ - xfs_alloc_wq =alloc_workqueue ("xfsalloc" ,WQ_MEM_RECLAIM ,0 ); + xfs_alloc_wq =alloc_workqueue ("xfsalloc" , +WQ_MEM_RECLAIM |WQ_FREEZABLE ,0 );if (!xfs_alloc_wq)return -ENOMEM ;
Signature · 6 lines
1.8.3.1 _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 10 lines · Brian Foster
Workqueues must be explicitly set as freezable to ensure they are frozen in the assocated part of the hibernation/suspend sequence. Freezing of workqueues and kernel threads is important to ensure that modifications are not made on-disk after the hibernation image has been created. Otherwise, the in-memory state can become inconsistent with what is on disk and eventually lead to filesystem corruption. We have reports of free space btree corruptions that occur immediately after restore from hibernate that suggest the xfs-eofblocks workqueue could be causing such problems if it races with hibernation.
Quoted 6 lines
Mark all of the internal XFS workqueues as freezable to ensure nothing changes on-disk once the freezer infrastructure freezes kernel threads and creates the hibernation image.
Signed-off-by Brian Foster <[email protected]>Reported-by Carlos E. R. <[email protected]>
Looks good.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs