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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
