I'm getting the following error on chard stacked XFS when doing rpmbuild --rebuild on SMP but haven't verified if this happens on UP either. It does not happen on csoft stacked XFS in UP and SMP. Using 2.6.11-ssi on FC3.
svrtok_dorelse: remove failed error = -2
Sometimes you will see the cfs_unlinkname renamed files in the original directory, not in the .cfs_unlink directory where they're expected to reside. For some reason they did not get moved to the .cfs_unlink directory. These renamed files probably have the DELAYEDUNLINK flag too because they weren't able to be removed by hand (until after a nodedown event?). We get the above error when trying to remove these renamed files.
Other times after seeing the error, the original files (not renamed) still reside in the original directory and can be removed by hand without running into the error again.
The error seems to be triggered only when doing rpmbuild --rebuild.
Trace at svrtok_dorelse() bp:
0xd130e070 239753 238254 1 1 R 0xd130e240 *rm
EBP EIP Function (args)
0xd17a3ed4 0xc028b0f0 svrtok_dorelse (0xc26d0e00, 0x0, 0xc2685080, 0xc26852bc, 0xc2685194)
0xc0288d62 svrtok_relse+0xb2 (0xc26d0e00, 0x0, 0x0, 0x2, 0xc2685194)
0xd17a3ef0 0xc027a3cc cfs_clear_inode+0x5c (0xc2685194, 0xc2685194, 0xc027a2e0)
0xd17a3f04 0xc017f846 clear_inode+0xd6 (0xc2685194, 0x0, 0x0, 0x2, 0xc2685194)
0xd17a3f20 0xc027a33a cfs_delete_inode+0x5a (0xc2685194, 0xf27dfce4, 0xd17a3f40, 0xc2685194, 0xd1164000)
0xd17a3f3c 0xc0180711 generic_delete_inode+0x71 (0xc2685194)
0xd17a3f48 0xc01808e8 generic_drop_inode+0x18 (0xc2685194, 0xc04e7bac, 0x0)
0xd17a3f5c 0xc0180961 iput+0x61 (0xc2685194, 0xf27dfce4, 0xf27dfce4, 0xf6241424, 0xf61cb980)
0xd17a3fbc 0xc017571e sys_unlink+0xee
cfs_delayedunlink should have been called before iput, so maybe there is a race in un/setting CFS_DELAYUNLNK flag.