Hi all:
we have a test about nfs on linux 4.11.
the detailed process as follow:
server ip:9.81.231.141 client
mount -t ext4 /dev/vdb /home/nfs/aa
mount -t nfs -o sync,tcp,vers=3,noac,timeo=70,retrans=3 9.81.231.141:/home/nfs /tmp/aa/
ls /tmp/aa
umount /home/nfs/aa
the umount remind "target is busy".
so we analyze the code , a reference count which is named "mnt_count" add 1 in rqst_exp_get_by_name() after execute the "ls" order.
the detailed call is nfsd3_proc_lookup->nfsd_lookup->nfsd_lookup_dentry->nfsd_cross_mnt->rqst_exp_get_by_name->exp_get_by_name->svc_export_lookup->sunrpc_cache_lookup->svc_export_init->path_get
the reference count can't be subtracted untill we stop nfsd or tcp idle timeout on server. the system call the cache_flush() to subtract the count.
then we can umount successfully.
do dou have some patches can umount immediately or some suggestions?
On Tue, May 16, 2017 at 08:57:03PM +0800, Gu Zheng wrote:
> Hi all:
> we have a test about nfs on linux 4.11.
> the detailed process as follow:
> server ip:9.81.231.141 client
> mount -t ext4 /dev/vdb /home/nfs/aa
> mount -t nfs -o sync,tcp,vers=3,noac,timeo=70,retrans=3 9.81.231.141:/home/nfs /tmp/aa/
> ls /tmp/aa
> umount /home/nfs/aa
This is as expected. There's actually no guarantee you'll be able to
unmount the filesystem till nfsd is stopped (even unexporting won't
always do the job).
--b.
>
> the umount remind "target is busy".
> so we analyze the code , a reference count which is named "mnt_count" add 1 in rqst_exp_get_by_name() after execute the "ls" order.
> the detailed call is nfsd3_proc_lookup->nfsd_lookup->nfsd_lookup_dentry->nfsd_cross_mnt->rqst_exp_get_by_name->exp_get_by_name->svc_export_lookup->sunrpc_cache_lookup->svc_export_init->path_get
> the reference count can't be subtracted untill we stop nfsd or tcp idle timeout on server. the system call the cache_flush() to subtract the count.
> then we can umount successfully.
>
> do dou have some patches can umount immediately or some suggestions?
Dear J. Bruce Fields
in nfs rfc wrote:
"Every NFS version 3 protocol client can also potentially be a
server, and remote and local mounted file systems can be
freely mixed. This leads to some problems when a client
travels down the directory tree of a remote file system and
reaches the mount point on the server for another remote file
system. Allowing the server to follow the second remote mount
would require loop detection, server lookup, and user
revalidation. Instead, both NFS version 2 protocol and NFS
version 3 protocol implementations do not typically let
clients cross a server's mount point. When a client does a
LOOKUP on a directory on which the server has mounted a file
system, the client sees the underlying directory instead of
the mounted directory.
For example, if a server has a file system called /usr and
mounts another file system on /usr/src, if a client mounts
/usr, it does not see the mounted version of /usr/src. A
client could do remote mounts that match the server's mount
points to maintain the server's view. In this example, the
client would also have to mount /usr/src in addition to /usr,
even if they are from the same server."
and now we do not set the crossmnt ,so that we saw is the underlying directory .
the nfs mount have no relation to ext4 mountpoint, it can be umounted maybe better.
can we add some limits to let it do not enter the nfsd_cross_mnt() in nfsd_lookup_dentry()if the crossmnt is not set?
best wishes!
在 2017/5/17 1:42, J. Bruce Fields 写道:
> On Tue, May 16, 2017 at 08:57:03PM +0800, Gu Zheng wrote:
>> Hi all:
>> we have a test about nfs on linux 4.11.
>> the detailed process as follow:
>> server ip:9.81.231.141 client
>> mount -t ext4 /dev/vdb /home/nfs/aa
>> mount -t nfs -o sync,tcp,vers=3,noac,timeo=70,retrans=3 9.81.231.141:/home/nfs /tmp/aa/
>> ls /tmp/aa
>> umount /home/nfs/aa
>
> This is as expected. There's actually no guarantee you'll be able to
> unmount the filesystem till nfsd is stopped (even unexporting won't
> always do the job).
>
> --b.
>
>>
>> the umount remind "target is busy".
>> so we analyze the code , a reference count which is named "mnt_count" add 1 in rqst_exp_get_by_name() after execute the "ls" order.
>> the detailed call is nfsd3_proc_lookup->nfsd_lookup->nfsd_lookup_dentry->nfsd_cross_mnt->rqst_exp_get_by_name->exp_get_by_name->svc_export_lookup->sunrpc_cache_lookup->svc_export_init->path_get
>> the reference count can't be subtracted untill we stop nfsd or tcp idle timeout on server. the system call the cache_flush() to subtract the count.
>> then we can umount successfully.
>>
>> do dou have some patches can umount immediately or some suggestions?
>
> .
>
On Wed, May 17, 2017 at 03:18:38PM +0800, Gu Zheng wrote:
> and now we do not set the crossmnt ,so that we saw is the underlying directory .
> the nfs mount have no relation to ext4 mountpoint, it can be umounted maybe better.
>
> can we add some limits to let it do not enter the nfsd_cross_mnt() in nfsd_lookup_dentry()if the crossmnt is not set?
If the problem is inability to unmount a filesystem that isn't actually
even exported, then it *might* be addressed by Kinglong Mee's patches:
http://lkml.kernel.org/r/[email protected]
I'm not sure what those patches still need--they may just be waiting for
my review.
--b
to J. Bruce Fields:
thanks for your supports.
to Kinglong Mee:
I warried about how to modify for supporting the expected unmount.
It is helpful to me after i saw the patchs,but it felt a little unreasonably in bellow scene:
if a filesystem is exported and i am in the mounted directory on client,the fs also can be umounted on server.
best wishes!
在 2017/5/17 23:46, J. Bruce Fields 写道:
> On Wed, May 17, 2017 at 03:18:38PM +0800, Gu Zheng wrote:
>> and now we do not set the crossmnt ,so that we saw is the underlying directory .
>> the nfs mount have no relation to ext4 mountpoint, it can be umounted maybe better.
>>
>> can we add some limits to let it do not enter the nfsd_cross_mnt() in nfsd_lookup_dentry()if the crossmnt is not set?
>
> If the problem is inability to unmount a filesystem that isn't actually
> even exported, then it *might* be addressed by Kinglong Mee's patches:
>
> http://lkml.kernel.org/r/[email protected]
>
> I'm not sure what those patches still need--they may just be waiting for
> my review.
>
> --b
>
> .
>