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.
> On Sep 15, 2021, at 04:03, zhangxiaoxu (A) <[email protected]> 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
[email protected]
?? 2021/9/15 21:05, Trond Myklebust д??:
>
>
>> On Sep 15, 2021, at 04:03, zhangxiaoxu (A) <[email protected]> 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
> [email protected]
>
> .
>
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)
> > > <[email protected]> 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
[email protected]