Re: Is "unmount -f" worked as expected?

["bfields@fieldses.org" <bfields@fieldses.org>]

On Thu, May 31, 2018 at 03:14:44PM +0000, Shawn Lu (shawlu) wrote:
>  Thanks Joshua for great help.   From context provided by joshua, I am
>  believe that the community is full aware of the “-f “ issue, but
>  still pending on solution. 
> 
>  Wondering whether community have consensus yet on what should be the
>  correct behavior for “ force unmount”?  I hope maintainer of NFS can
>  give some guardian for direction.
> 
> My use case is also on embedded system where NFS server can go offline
> unexpected. What I looks for is something that can aggressive umount
> NFS in timely manner.  Data loss is secondly in my situation.

Dumb question: in that case, why not just cut power?

> One case is involved with  cross mounted nfs from different host.

Note: in theory I think there are some deadlocks possible if client and
server mount each other.  (Each host could be waiting on the other one
to process writes before it can free memory that it needs to make
progress.)

--b.

> Here,
> both server and client will be  shutdown at same time on reboot.  NFS
> client side will stuck on shutdown for long time if “umount –l”  is
> used to umount NFS.
> 
> The previous work done by Joshua and  Neil Brown will definitely help
> to resolve my use case if patch can be up streamed.  Hope magic will
> happen soon . 
> 
> Just wondering whether a kernel configure (eg.
> CONFIG_NFS_AGRRESSIVE_SHUTDOWN)  can be added to enhance “force
> umount “ to act more aggressive.  This feature will be off by default
> so the admin use to the “soft “ force mount will get the same behavior
> as before.  When the feature is turn on,  “umount –f”  is Guarantee to
> succeed.