]> CyberLeo.Net >> Repos - FreeBSD/releng/9.2.git/commit
MFS of 255104:
authormckusick <mckusick@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Thu, 5 Sep 2013 04:00:48 +0000 (04:00 +0000)
committermckusick <mckusick@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Thu, 5 Sep 2013 04:00:48 +0000 (04:00 +0000)
commit39f9ce077570b536b034b0df312947fc1279019c
tree3453e7385f5d1d54dfc92de496dccd08abf91c09
parent384e2f563dd8656e4ec887af14c3ce58b90c06db
MFS of 255104:
MFC of 253998:

This bug fix is in a code path in rename taken when there is a
collision between a rename and an open system call for the same
target file. Here, rename releases its vnode references, waits for
the open to finish, and then restarts by reacquiring its needed
vnode locks. In this case, rename was unlocking but failing to
release its reference to one of its held vnodes. The effect was
that even after all the actual references to the vnode had gone,
the vnode still showed active references. For files that had been
removed, their space was not reclaimed until the filesystem was
forcibly unmounted.

This bug manifested itself in the Postgres server which would
leak/lose hundreds of files per day amounting to many gigabytes of
disk space. This bug required shutting down Postgres, forcibly
unmounting its filesystem, remounting its filesystem and restarting
Postgres every few days to recover the lost space.

Reported by: Dan Thomas and Palle Girgensohn
Bug-fix by:  kib
Tested by:   Dan Thomas and Palle Girgensohn

Approved by: re@ (Marius Strobl <marius@freebsd.org>)

git-svn-id: svn://svn.freebsd.org/base/releng/9.2@255231 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
sys/ufs/ufs/ufs_vnops.c