I filed the bug but it hasn't shown up in the bug database yet.
In the meanwhile, this problem became more critical for me, so I took a stab at
it and think I have a fix.
The file never gets put on the ufs delete queue because it's vnop's vn_count
never reaches 1 in vn_rele(). The extra hold is coming from the dnlc entry for
the file's xattrdir which puts a hold on the xattrdir and it's parent file. I
added a dnlc_remove for the xattrdir in ufs_dirremove() and this seems to fix
the problem.
Here is the patch. I'd attach this info to the bug, but like I said it hasn't
shown up yet.
*** ufs_dir.c.orig 2008-01-30 14:06:37.000000000 -0600
--- ufs_dir.c 2008-01-30 14:05:40.000000000 -0600
***************
*** 2613,2618 ****
--- 2613,2625 ----
ep = slot.ep;
ep->d_ino = 0;
+ /* If there is an xattrdir on this file, attempt a dnlc removal of
+ * the XATTRDIR from this file. Otherwise it will have an extra count
which
+ * causes the space for this file to not be reclaimed.
+ */
+ if (ip->i_oeftflag)
+ dnlc_remove(vp, XATTR_DIR_NAME);
+
if (slot.cached) {
dcanchor_t *dcap = &dp->i_danchor;
This message posted from opensolaris.org
_______________________________________________
ufs-discuss mailing list
[email protected]
