On Thu, 2017-03-09 at 15:46 +1100, NeilBrown wrote:
> On Thu, Mar 09 2017, NeilBrown wrote:
>
> > I've been chasing down a problem where a customer has a localhost
> > mount,
> > and the sequence
> > unmount -at nfs,nfs4
> > stop nfsserver
> > sync
> >
> > hangs on the sync. The 'sync' is trying to write to the NFS
> > filesystem
> > that has just been unmounted.
So why can't you move the sync up one line?
> > I have duplicated the problem on a current mainline kernel.
> >
> > There are two important facts that lead to the explanation of this.
> > 1/ whenever a 'struct file' is open, an s_active reference is held
> > on
> > the superblock, via "open_context" calling nfs_sb_active().
> > This doesn't prevent "unmount" from succeeding (i.e. EBUSY isn't
> > returned), but does prevent the actual unmount from happening
> > (->kill_sb() isn't called).
> > 2/ When a memory mapping of a file is torn down, the file is
> > "released", causing the context to be discarded and the
> > sb_active
> > reference released, but unlike close(2), file_operations-
> > >flush()
> > is not called.
>
> I realised that there is another piece of the puzzle.
> When a page is marked dirty (e.g. nfs_vm_page_mkwrite),
> nfs_updatepage() -> nfs_writepage_setup()
> creates a 'struct nfs_page' request which holds a reference to
> the open context, which in turn holds an active reference to the
> superblock.
> So as long as there are dirty pages, the superblock will not go
> inactive. All the rest still holds.
>
> NeilBrown
>
>
> >
> > Consequently, if you:
> > open an NFS file
> > mmap some pages PROT_WRITE
> > close the file
> > modify the pages
> > unmap the pages
> > unmount the filesystem
> >
> > the filesystem will remain active, and the pages will remain dirty.
> > If you then make the nfs server unavailable - e.g. stop it, or tear
> > down
> > the network connection - and then call 'sync', the sync will hang.
> >
> > This is surprising, at the least :-)
> >
> > I have two ideas how it might be fixed.
> >
> > One is to call nfs_file_flush() from within nfs_file_release().
> > This is probably simplest (and appears to work).
> >
> > The other is to add a ".close" to nfs_file_vm_ops. This could
> > trigger a
> > (partial) flush whenever a page is unmapped. As closing an NFS
> > file
> > always triggers a flush, it seems reasonable that unmapping a page
> > would trigger a flush of that page.
> >
> > Thoughts?
> >
All this is working as expected. The only way to ensure that data is
synced to disk by mmap() is to explicitly call msync(). This is well
documented, and should be well understood by application developers. If
those developers are ignoring the documentation, then I suggest votoing
with your feet and getting your software from someone else.
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@xxxxxxxxxxxxxxx
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
