* Questions about nfs_sb_active
@ 2021-09-15 8:03 zhangxiaoxu (A)
2021-09-15 13:05 ` Trond Myklebust
0 siblings, 1 reply; 4+ messages in thread
From: zhangxiaoxu (A) @ 2021-09-15 8:03 UTC (permalink / raw)
To: Linux NFS Mailing List, Trond Myklebust, Anna Schumaker
Cc: Luo Meng, zhangyi (F)
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.
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: Questions about nfs_sb_active 2021-09-15 8:03 Questions about nfs_sb_active zhangxiaoxu (A) @ 2021-09-15 13:05 ` Trond Myklebust 2021-09-16 3:48 ` zhangxiaoxu (A) 0 siblings, 1 reply; 4+ messages in thread From: Trond Myklebust @ 2021-09-15 13:05 UTC (permalink / raw) To: zhangxiaoxu (A) Cc: Linux NFS Mailing List, Anna Schumaker, Luo Meng, zhangyi (F) > On Sep 15, 2021, at 04:03, zhangxiaoxu (A) <zhangxiaoxu5@huawei.com> wrote: > > 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. That has nothing to do with I/O. Delegations are state. _________________________________ Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@hammerspace.com ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Questions about nfs_sb_active 2021-09-15 13:05 ` Trond Myklebust @ 2021-09-16 3:48 ` zhangxiaoxu (A) 2021-09-16 14:23 ` Trond Myklebust 0 siblings, 1 reply; 4+ messages in thread From: zhangxiaoxu (A) @ 2021-09-16 3:48 UTC (permalink / raw) To: Trond Myklebust Cc: Linux NFS Mailing List, Anna Schumaker, Luo Meng, zhangyi (F) 在 2021/9/15 21:05, Trond Myklebust 写道: > > >> On Sep 15, 2021, at 04:03, zhangxiaoxu (A) <zhangxiaoxu5@huawei.com> wrote: >> >> 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. > > That has nothing to do with I/O. Delegations are state. Since the callbacks hold the 'sb->s_active', the umount maybe return success without shutdown the superblock. In general, the superblock should be shutdown before umount success, but in the concurrent scenario, the superblock is shutdown after the callbacks finish. If the system is crashed in this period, we may lost 'sync_filesystem', then the page caches (which not flush to server since hold the write delegation when close the file) and metadata caches maybe lost? And the 'fsnotify_sb_delete' is also called after the callbacks finish. IOW, the umount already return with success, but the FS_UNMOUNT event maybe delay? I have no idea about it is reasonable or not. > > _________________________________ > Trond Myklebust > Linux NFS client maintainer, Hammerspace > trond.myklebust@hammerspace.com > > . > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Questions about nfs_sb_active 2021-09-16 3:48 ` zhangxiaoxu (A) @ 2021-09-16 14:23 ` Trond Myklebust 0 siblings, 0 replies; 4+ messages in thread From: Trond Myklebust @ 2021-09-16 14:23 UTC (permalink / raw) To: zhangxiaoxu5; +Cc: linux-nfs, luomeng12, anna.schumaker, yi.zhang On Thu, 2021-09-16 at 11:48 +0800, zhangxiaoxu (A) wrote: > > > 在 2021/9/15 21:05, Trond Myklebust 写道: > > > > > > > On Sep 15, 2021, at 04:03, zhangxiaoxu (A) > > > <zhangxiaoxu5@huawei.com> wrote: > > > > > > 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. > > > > That has nothing to do with I/O. Delegations are state. > Since the callbacks hold the 'sb->s_active', > the umount maybe return success without shutdown the superblock. > > In general, the superblock should be shutdown before umount success, > but in the concurrent scenario, the superblock is shutdown after the > callbacks finish. > > If the system is crashed in this period, we may lost > 'sync_filesystem', > then the page caches (which not flush to server since hold the write > delegation when close the file) > and metadata caches maybe lost? No. We still flush writes on close. Even if that were the case, then it is no different from the behaviour of block devices. > > And the 'fsnotify_sb_delete' is also called after the callbacks > finish. > IOW, the umount already return with success, but the FS_UNMOUNT event > maybe delay? > > I have no idea about it is reasonable or not. > > I do. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@hammerspace.com ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-09-16 14:23 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-09-15 8:03 Questions about nfs_sb_active zhangxiaoxu (A) 2021-09-15 13:05 ` Trond Myklebust 2021-09-16 3:48 ` zhangxiaoxu (A) 2021-09-16 14:23 ` Trond Myklebust
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).