linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/8] simplify reconnecting dentries looked up by filehandle (v2)
@ 2013-10-25 20:29 J. Bruce Fields
  2013-10-25 20:29 ` [PATCH 1/8] exportfs: BUG_ON in crazy corner case J. Bruce Fields
                   ` (4 more replies)
  0 siblings, 5 replies; 14+ messages in thread
From: J. Bruce Fields @ 2013-10-25 20:29 UTC (permalink / raw)
  To: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
  Cc: Christoph Hellwig, Al Viro, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
	J. Bruce Fields

From: "J. Bruce Fields" <bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

This is a revised version of patches to simplify the code that
reconnects directories looked up by filehandle.  Thanks to Christoph for
review.  Changes since v1 include:

	- BUG_ON finding a filesystem root with DCACHE_DISCONNECTED
	- fix some dentry reference leaks
	- only do the dentry_connected() check when we actually hit a
	  race--it's redundant in the normal case.
	- simplify some of the logic
	- add detail to changelogs and comments
	- sequence the patches slightly differently (hopefully it's
	  clearer)

Christoph, I credited one minor patch to you, and I ignored several
Reviewed-by's you posted since I wasn't sure if you'd want them on the
revised patches.

The following explanation is mostly unchanged from before, including the
performance results.  (I didn't redo them, but a couple quick checks
didn't suggest any significant difference from the revisions.)

--b.

When we lookup a filehandle for a directory not already in the dentry
cache, fs/exportfs/expfs.c:reconnect_path() is what populates the dentry
cache with the directory and its parents.

The current code is more complicated than necessary:

	- after looking up the parent, it searches the parent directory
	  for our target dentry.  If that search fails with -ENOENT, it
	  retries up to 10 times.  I don't understand why.  This should
	  only happen if there's a concurrent rename or rmdir, in which
	  case that concurrent operation should have reconnected the
	  dentry for us, and we're done.

	- each time it succesfully connects a dentry to its parent, it
	  restarts from scratch with the original dentry.  Why not
	  continue working with the parent we just found?

Patches showing the resulting simplification follow.

I tested performance with a script that creates an N-deep directory
tree, gets a filehandle for the bottom directory, writes 2 to
/proc/sys/vm/drop_caches, then times an open_by_handle_at() of the
filehandle.  Code at

	git://linux-nfs.org/~bfields/fhtests.git

For directories of various depths, some example observed times (median
results of 3 similar runs, in seconds), were:

		depth:	8000	2000	200
	no patches:	11	0.7	0.02
	all patches:	 0.1	0.03	0.01

For depths < 2000 I used an ugly hack to shrink_slab_node() to force
drop_caches to free more dentries.  Difference look lost in the noise
for much smaller depths.

Nesting that deep sounds crazy to me, and cold lookup of a
filehandle isn't the common case.  But maybe it's worth not having to
worry about the awful performance in these pathalogical cases.  And it
does simplify the code.

Christoph Hellwig (1):
  exportfs: BUG_ON in crazy corner case

J. Bruce Fields (7):
  exportfs: more detailed comment for path_reconnect
  exportfs: clear DISCONNECTED on all parents sooner
  exportfs: stop retrying once we race with rename/remove
  exportfs: eliminate unused "noprogress" counter
  exportfs: move most of reconnect_path to helper function
  exportfs: better variable name
  exportfs: fix quadratic behavior in filehandle lookup

 fs/exportfs/expfs.c |  249 +++++++++++++++++++++++++++------------------------
 1 file changed, 133 insertions(+), 116 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2013-10-30 16:38 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-25 20:29 [PATCH 0/8] simplify reconnecting dentries looked up by filehandle (v2) J. Bruce Fields
2013-10-25 20:29 ` [PATCH 1/8] exportfs: BUG_ON in crazy corner case J. Bruce Fields
     [not found] ` <1382733005-6006-1-git-send-email-bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-10-25 20:29   ` [PATCH 2/8] exportfs: more detailed comment for path_reconnect J. Bruce Fields
2013-10-25 20:30   ` [PATCH 3/8] exportfs: clear DISCONNECTED on all parents sooner J. Bruce Fields
2013-10-25 20:30   ` [PATCH 4/8] exportfs: stop retrying once we race with rename/remove J. Bruce Fields
     [not found]     ` <1382733005-6006-5-git-send-email-bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-10-27  7:04       ` NeilBrown
     [not found]         ` <20131027180409.66037e01-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2013-10-28  8:53           ` Christoph Hellwig
2013-10-28 15:08         ` J. Bruce Fields
2013-10-25 20:30   ` [PATCH 7/8] exportfs: better variable name J. Bruce Fields
2013-10-30 16:10   ` [PATCH 0/8] simplify reconnecting dentries looked up by filehandle (v2) Christoph Hellwig
     [not found]     ` <20131030161013.GA19668-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2013-10-30 16:38       ` J. Bruce Fields
2013-10-25 20:30 ` [PATCH 5/8] exportfs: eliminate unused "noprogress" counter J. Bruce Fields
2013-10-25 20:30 ` [PATCH 6/8] exportfs: move most of reconnect_path to helper function J. Bruce Fields
2013-10-25 20:30 ` [PATCH 8/8] exportfs: fix quadratic behavior in filehandle lookup J. Bruce Fields

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).