[Tux3] Deferred namespace operations, Defer rename

[Daniel Phillips]

This diff adds deferred rename.  Unlike the patch iterations before it, 
this one actually shrinks the code, because the directory sync handler 
does linking and unlinking for rename just like it does for other 
namespace operations.  All we have to do is set the BACKED and STALE 
flags on the dentries involved appropriately.

The position vacated by the moved dentry has to be filled in with a 
negative dentry to prevent the vfs from discovering the dirent still on 
the filesystem.  If the source dentry was BACKED or STALE (that is, an 
entry exists on disk) then the clone is marked STALE.  The source 
dentry is going to be d_moved to take the place of the target dentry,  
so if the target dentry is BACKED or STALE then the source dentry is 
marked STALE so that the existing target dirent will be removed.

This works pretty well with non-directories as far as I have tested it.  
If a directory is being moved, then I fail to update the directory's 
dotdot dirent, which is pretty easy to fix.  A much harder problem is 
knowing when a directory is empty.  Scanning through all the dirent 
blocks to find out, as Ext2 has traditionally done, gives an incorrect 
answer if some unlinks have been deferred.  For some strange reason, 
directory link count only includes subdirectories, not regular files or 
other kinds of entries, so that cannot be relied on.  I am not sure 
what the right thing to do here is.  At worst, a flush could be forced 
before deleting a directory, then the traditional check will work.  Or 
we can do a dcache lookup for each dirent still found in the directory 
(the cached_lookup function in namei.c does this, and could just be 
exported).

Anyway, the deferred namespace operations patch now goes on the back 
burner.  The effort so far has basically proven the idea, I think, and 
opens up a path to a powerful optimization we can do later.  Of course 
I am interested in comments, bugs, criticism, test reports or whatever 
on this patch, regardless, and probably will do a little cleanup work 
on it.  But now we want to focus on base functionality and decent 
performance, so back to the basics, which are atomic commit and smp 
locking.

Regards,

Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: defer.diff
Type: text/x-diff
Size: 2947 bytes
Desc: not available
URL: <http://phunq.net/pipermail/tux3/attachments/20081214/bd81bd42/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: defer.patch
Type: text/x-diff
Size: 18938 bytes
Desc: not available
URL: <http://phunq.net/pipermail/tux3/attachments/20081214/bd81bd42/attachment.patch>
-------------- next part --------------
_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3