Date: Wed, 29 May 2013 17:00:01 GMT From: Jaakko Heinonen <jh@FreeBSD.org> To: freebsd-fs@FreeBSD.org Subject: Re: kern/165392: Multiple mkdir/rmdir fails with errno 31 Message-ID: <201305291700.r4TH01uG081930@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/165392; it has been noted by GNATS. From: Jaakko Heinonen <jh@FreeBSD.org> To: Jilles Tjoelker <jilles@stack.nl> Cc: bug-followup@FreeBSD.org, vvv@colocall.net, mckusick@FreeBSD.org Subject: Re: kern/165392: Multiple mkdir/rmdir fails with errno 31 Date: Wed, 29 May 2013 19:53:11 +0300 On 2013-05-27, Jilles Tjoelker wrote: > > 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". > > fsync certainly helps but not as effectively as you'd want. Some > combination of sleeps, fsyncs and mkdir attempts appears to be needed. I have revised the patch and the following version _appears_ to work. http://people.freebsd.org/~jh/patches/ufs-check_linkcnt.2.diff It's still experimental and doesn't handle link(2) or rename(2) at all. In my testing debug.softdep.linkcnt_retries is increased by one with your original reproduction recipe. > I'm also interested in whether it is safe to call VOP_FSYNC at that > point, especially in the case of a rename where a lock on the source > directory vnode may be held at the same time. I think your concern is valid because softdep_fsync() needs to lock parent directories. Possibly you can work around the problem by unlocking the vnodes, doing fsync and then restarting rename. Unfortunately this makes rename even more complex. -- Jaakko
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201305291700.r4TH01uG081930>