Re: 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 <j...@FreeBSD.org>
To: Jilles Tjoelker <jil...@stack.nl>
Cc: bug-fo...@FreeBSD.org, v...@colocall.net, mcku...@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
_______________________________________________
freeb...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-...@freebsd.org"