Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
To:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        Trond Myklebust <trondmy@hammerspace.com>,
        Anna Schumaker <anna.schumaker@netapp.com>
CC:     Luo Meng <luomeng12@huawei.com>,
        "zhangyi (F)" <yi.zhang@huawei.com>
From:   "zhangxiaoxu (A)" <zhangxiaoxu5@huawei.com>
Subject: Questions about nfs_sb_active
Message-ID: <ce24474a-39a6-dc3b-0580-378cdfedf0c5@huawei.com>
Date:   Wed, 15 Sep 2021 16:03:19 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.7.1
MIME-Version: 1.0
Content-Type: text/plain; charset="gbk"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi Trond,

I have some confuse about 'nfs_sb_active'.

The following commit increase the 'sb->s_active' to prevent concurrent with umount process when handle the callback rpc message.

   e39d8a186ed0 ("NFSv4: Fix an Oops during delegation callbacks")
   113aac6d567b ("NFS: nfs_delegation_find_inode_server must first reference the superblock")

But it also delay the process in function 'generic_shutdown_super', such as 'sync_filesystem' and 'fsnotify_sb_delete'.

For the common file system, when umount success, the data should be stable to the disk, but in nfs, it maybe delay?

I want know :
   1. whether we _must_ stable the data to the server?
   2. how to ensure the data not lost when umount success but client crash?
   3. the delayed fsnotify umount event is reasonable or not?
   4. the 'nfs_sb_active' should be used under what scenario?

Thanks.