[SSI-devel] [ ssic-linux-Bugs-1687741 ] CFS delayed unlink not working on XFS
Brought to you by:
brucewalker,
rogertsang
Menu
▾
▴
[SSI-devel] [ ssic-linux-Bugs-1687741 ] CFS delayed unlink not working on XFS
|
From: SourceForge.net <no...@so...> - 2007-04-10 00:30:55
|
Bugs item #1687741, was opened at 2007-03-25 04:29 Message generated for change (Comment added) made by rogertsang You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=405834&aid=1687741&group_id=32541 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Filesystem Group: v1.9.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roger Tsang (rogertsang) Assigned to: Nobody/Anonymous (nobody) Summary: CFS delayed unlink not working on XFS Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Roger Tsang (rogertsang) Date: 2007-04-09 20:30 Message: Logged In: YES user_id=1246761 Originator: YES After more code review: - CFS_DELAYUNLNK flag does not need spinlock in most places because most of the callers have token. - Seems faster to delay flushing the cfs cache until next time someone has acquired token. - Bug: cfsd_rename call to cfs_delayedunlink creates a link in origin directory not .cfs_unlink directory. Hence svrtok_dorelse error -2. (Why does CFS stacked ext3 not see this bug?) ---------------------------------------------------------------------- Comment By: Roger Tsang (rogertsang) Date: 2007-03-26 20:43 Message: Logged In: YES user_id=1246761 Originator: YES There are a few things to address: - Many places CFS_DELAYUNLNK flag not SMP safe. - Where in cfstok_req does it revalidate inode? I'm currently testing with new code to cfstok_objrevoke in cfstok_req whenever cfs_zap_caches. - Someone to explain why they want to flush async writes at end of cfs_unlink. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=405834&aid=1687741&group_id=32541 |