Hey Dave, This is going to spin over the weekend. See what you think. -- xfs: shutdown xfs_sync_worker before the log Revert commit 1307bbd, which uses the s_umount semaphore to provide exclusion bet
I'm reasonably satisfied with the test results over the weekend. I did end up hitting an unrelated assert: [137111.090394] XFS: Assertion failed: (iflags & BMV_IF_DELALLOC) != 0, file: /root/xfs/fs/x
I started testing the xfsaild idle patch based against the xfs tree over the weekend (after testing successfully against Linus' tree for several days) and reproduced the xfs_sync_worker() hang that M
Hey Brian, D'oh! The xfs_sync_worker hang that Mark mentioned last week is when the sync worker blocks on log reservation for the dummy transaction used to cover the log, which means that it will not
Ah, ok. Thanks for the context and sorry for the noise in this thread. I do find it interesting that I hit this rather quickly after so many hours of testing on Linus' tree without seeing it once. I
xfs: shutdown xfs_sync_worker before the log Revert commit 1307bbd, which uses the s_umount semaphore to provide exclusion between xfs_sync_worker and unmount, in favor of shutting down the sync wor
Looks fine to me. Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx> Once you commit this, I think I'll do a followup set of patches that remove all the problems caused by trying to start and stop unrel
Hey Dave, Thanks! I think that's a good idea. That sounds pretty good. In particular, I think that making the start and stop of the workqueues correct should be the high priority. I'm not as concerne
That sounds pretty good. In particular, I think that making the start and stop of the workqueues correct should be the high priority. I'm not as concerned about the accuracy of the names, or cleanin
It is supposed to be already idle before the log is torn down. The log is forced synchronously while flushes remaining CIL items, then the AIL is emptied synchronously. That should result in no outst
That sounds pretty good. In particular, I think that making the start and stop of the workqueues correct should be the high priority. I'm not as concerned about the accuracy of the names, or cleanin
Oh, well that makes it easy to find the bug. Took me about 10s to work it out with that information, without even looking at the code. ;) So, have a look at xfs_unmountfs(), what it does with the sup
I like the cancel_delayed_work_sync on unmount side of this, but I don't really like the MS_ACTIVE check - why can't we only do the initial xfs_syncd_queue_sync as the last thing in the mount process
Is there any good reason to keep queueing different work items on the same queue now that workqueues are incredibly cheap? Sounds good. You probably also want to kill off xfs_sync_fsdata as it doesn'
Hey Christoph, There isn't a race on the mount side related to the MS_ACTIVE flag. It's only on the unmount side. I agree that we could get rid of the MS_ACTIVE check if we move xfs_syncd_queue_sync
That's what i plan to fix as a followup - this is really just the minimal fix to solve the problem at hand for 3.5.... The laptop mode stuff has bit rotted for a long time - I've never really cared a