[lkml]   [2010]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.6.34rc4 NFS writeback regression (bisected): client often fails to delete things it just created
On Sat, 2010-04-17 at 20:43 +0100, Nix wrote: 
> [Trond Cc:ed as this seems to be a bug in one of your
> writeback-for-2.6.34 commits.]
> In 2.6.34rcX (tip of tree) I've started seeing this sort of thing when
> building over NFS (v3):
> [...]
> -- Found LibXslt: /usr/lib64/
> -- found libxml-2.0, version 2.7.6
> -- Found LibXml2: /usr/lib64/
> -- Found shared-mime-info version: 0.71
> -- Looking for __progname
> CMake Error: Remove failed on file: /usr/src/kde/x86_64-mutilate/build/CMakeFiles/CMakeTmp/CMakeFiles/cmTryCompileExec.dir/.nfs000000000031fc510000082f: System Error: Device or resource busy
> [... eventually, cmake fails because of this error.]
> The silly-renamed files are invariably no longer in use (they tend to be
> GCC output, ELF executables run as part of testsuites) but haven't been
> removed, and they -EBUSY when removal is attempted.
> A complete strace log of running cmake against current HEAD (with lots
> of these errors) is at
> <>.
> I can do a packet capture too if you like.
> I also see it after doing 'make install's followed by an 'rm -rf' of the
> build tree: the rm -rf fails because half the files are 'in use' (they
> aren't). Repeating the rm -rf a few seconds later works. fuser, even as
> root, shows no processes holding these files open.
> This bisects down to
> commit acdc53b2146c7ee67feb1f02f7bc3020126514b8
> Author: Trond Myklebust <>
> Date: Fri Feb 19 17:03:26 2010 -0800
> NFS: Replace __nfs_write_mapping with sync_inode()
> Now that we have correct COMMIT semantics in writeback_single_inode, we can
> reduce and simplify nfs_wb_all(). Also replace nfs_wb_nocommit() with a
> call to filemap_write_and_wait(), which doesn't need to hold the
> inode->i_mutex.
> With that done, we can eliminate nfs_write_mapping() altogether.
> Signed-off-by: Trond Myklebust <>
> I suspect that unlink()ing a not otherwise open file for which writeback
> is still underway is causing the files to be sillyrenamed because
> writeback is holding them open. If writeback is the only user, they
> should surely not be held open: nobody cares what their contents are,
> and a lot of code depends on rm -r of directories containing recently-
> written-but-still-closed files succeeding.

Did you test with commit b80c3cb628f0ebc241b02e38dd028969fb8026a2 (NFS:
Ensure that writeback_single_inode() calls write_inode() when syncing)?
That fixed the above problem on my setup.


 \ /
  Last update: 2010-04-18 21:23    [W:0.052 / U:1.744 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site