Date: Tue, 30 Jun 2009 12:01:21 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Attilio Rao <attilio@freebsd.org> Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: umount -f implementation Message-ID: <Pine.GSO.4.63.0906301150370.10386@muncher.cs.uoguelph.ca> In-Reply-To: <3bbf2fe10906290256x4bfbe263jccef017a557f9410@mail.gmail.com> References: <Pine.GSO.4.63.0906281955160.5084@muncher.cs.uoguelph.ca> <3bbf2fe10906290256x4bfbe263jccef017a557f9410@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 29 Jun 2009, Attilio Rao wrote: > > While that should be real in principle (immediate shutdown of the fs > operation and unmounting of the partition) it is totally impossible to > have it completely unsleeping, so it can happen that also umount -f > sleeps / delays for some times (example: vflush). > Currently, umount -f is one of the most complicated thing to handle in > our VFS because it puts as requirement that vnodes can be reclaimed in > any moment, adding complexity and possibility for races. > > What's the fix for your problem? > >From other responses, it does look like pursuing this is appropriate and that current behaviour is considered a bug. I should have noted in the previous email that I suspected that my simple patch didn't handle all cases, which I have just determined via testing. Unfortunately, the thread doing "umount" can also get stuck in an msleep() while waiting for the mnt_lockref to go to 0, which happens before the VFS_UNMOUNT() call. (mnt_lockref gets incremented by various system calls that call vfs_busy().) I think I can fix this in the experimental nfsv4 client, since it has a kernel thread that can check for MNTK_UNMOUNTF being set and then kill off the RPCs in progress, but that won't help the regular client. It's starting to look like too much work for FreeBSD8, but sounds like it is worth pursuing. (Appologies to anyone that thought I would have it all fixed in a day or two.) rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.63.0906301150370.10386>