I have talked about the benefits of deferring namespace operations such
as file create and unlink. For Tux3, the main motivation is to remove
the need to share write access to inode table blocks between front end
filesystem operations and back end cache flushing. There are other
good reasons for doing it too:
* Take long-running filesystem operations outside the i_mutex
directory lock, which is heavily contented in some situations
* Maybe there are opportunities to batch up edits to directory
blocks and perform them more efficiently
* Can sometimes handle a create-delete sequence entirely in cache
Anyway, here is a very crude patch that just defers unlinks of regular
files under Ext2. It relies on receiving an "fsync" to the directory to
actually remove the name from the directory entry block. I wrote a
little fsync utility for doing that:
#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>
int main(int argc, char *argv[])
{
if ((fsync(open(argv[1], O_RDONLY))) == -1) {
printf("failed to fsync %s: %s (%i)\n", argv[1], strerror(errno), errno);
}
return 0;
}
Hirofumi showed how it can be done with dd too, a nice trick. Anyway,
after a rm, the fsync has to be done by hand or the on-disk unlink will
never happen. But if you ls the directory, it will seem to be gone and
it cannot be opened. To be precise, the dentry for the file has been
turned into a "negative dentry" that says "this file does not exist",
and the negative dentry is locked into cache so that the filesystem
unlink can be done later. Of course, Ext3 will keep track of
directories that have deferred unlinked dentries, and automatically do
the fsync.
Besides the dentry, the cached inode has to be freed if its link count
has reached zero. We want to defer the inode free also, it is the
inode delete that causes the Tux3 layering problem described ...
