suspending threads before devices

John Baldwin jhb at freebsd.org
Wed Nov 19 19:21:17 UTC 2014


On Tuesday, November 18, 2014 08:43:09 PM Warner Losh wrote:
> On Nov 18, 2014, at 3:21 PM, John Baldwin <jhb at FreeBSD.org> wrote:
> > I would certainly like a way to quiesce threads before entering the real
> > suspend path.  I would also like to cleanly unmount filesystems during
> > suspend as well and the thread issue is a prerequisite for that. 
> > However, reusing "stop at boundary" may not be quite correct because you
> > probably don't want to block suspend because you have an NFS request that
> > is retrying due to a down NFS server.  For NFS I think you want any
> > threads asleep to just not get a chance to run again until after resume
> > completes.
> 
> I’m almost certain you don’t want to “unmount” the filesystems. This would
> invalidate all open file handles and would be mondo-bado, and would only
> succeed if you forced this issue due to all the open references. Perhaps
> you’re being imprecise.

Yes, there should have been quotes around unmount.  I want a 
VFS_SUSPEND/VFS_RESUME that for local filesystems (e.g. UFS) does the on-disk 
equivalent of unmount.  (Flush dirty buffers and mark filesystem as clean.)  
You really want this for S4 and even for S3 so you don't have to fsck if 
resume fails.  BTW, I think for network or userland filesystems you just punt 
on this (i.e. VFS_SUSPEND is a no-op or best-effort at most)

-- 
John Baldwin


More information about the freebsd-arch mailing list