Date: Mon, 29 Jun 2009 11:56:11 +0200 From: Attilio Rao <attilio@freebsd.org> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: umount -f implementation Message-ID: <3bbf2fe10906290256x4bfbe263jccef017a557f9410@mail.gmail.com> In-Reply-To: <Pine.GSO.4.63.0906281955160.5084@muncher.cs.uoguelph.ca> References: <Pine.GSO.4.63.0906281955160.5084@muncher.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/6/29 Rick Macklem <rmacklem@uoguelph.ca>: > I just noticed that when I do the following: > - start a large write to an NFS mounted fs > - network partition the server (unplug a net cable) > - do a "umount -f <mntpoint>" on the machine > > that it gets stuck trying to write dirty blocks to the server. > > I had, in the past, assumed that a "umount -f" of an NFS mount would be > used to get rid of an NFS mount on an unresponsive server and that loss > of "writes in progress" would be expected to happen. > > Does that sound correct? (In other words, an I seeing a bug or a feature?) 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? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10906290256x4bfbe263jccef017a557f9410>