kern/165392: Multiple mkdir/rmdir fails with errno 31

[Jaakko Heinonen]

The following reply was made to PR kern/165392; it has been noted by GNATS.

From: Jaakko Heinonen <jh at FreeBSD.org>
To: Jilles Tjoelker <jilles at stack.nl>
Cc: bug-followup at FreeBSD.org, vvv at colocall.net, mckusick at FreeBSD.org
Subject: Re: kern/165392: Multiple mkdir/rmdir fails with errno 31
Date: Mon, 20 May 2013 22:21:34 +0300

 Hi!
 
 On 2012-02-25, Jilles Tjoelker wrote:
 >  > [mkdir fails with [EMLINK], but link count < LINK_MAX]
 >  
 >  I can reproduce this problem with UFS with soft updates (with or without
 >  journaling).
 >  
 >  A reproduction without C programs is:
 >  
 >  cd empty_dir
 >  mkdir `jot 32766 1`     # the last one will fail (correctly)
 >  rmdir 1
 >  mkdir a                 # will erroneously fail
 >  
 >  The problem appears to be because the previous rmdir has not yet been
 >  fully completed. It is still holding onto the link count until the
 >  directory is written, which may take up to two minutes.
 >  
 >  The same problem can occur with other calls that increase the link count
 >  such as link() and rename().
 >  
 >  A workaround is to call fsync() on the directory that contained the
 >  deleted entries. It will then release its hold on the link count and
 >  allow mkdir or other calls. If fsync() is only called when [EMLINK] is
 >  returned, the performance impact should not be very bad, although it
 >  still causes more I/O than necessary.
 
 I tried to implement this with the following patch:
 
 	http://people.freebsd.org/~jh/patches/ufs-check_linkcnt.diff
 
 However, VOP_FSYNC(9) with the MNT_WAIT flag seems not to update the
 i_nlink count for a reason unknown to me. I can verify that also by
 taking your reproduction recipe above and adding "fsync ." between
 "rmdir 1" and "mkdir a".
 
 Does this mean that fsync(2) is broken for directories on softdep
 enabled UFS?
 
 I have cc'd Kirk in hope he could shed some light on this.
 
 -- 
 Jaakko