One of our users has just been in touch and reported slow file deletion (in this case the virtual disk for a VM) which was particularly impactful in the case of the Citrix Hypervisor control code as we hold a number of locks while deleting VM virtual disks and in this case the file delete took ~40 seconds to complete.
Now, we can, and will, work around this in the hypervisor control code by dropping the database entries under the locks and then leave the actual file deletion process occur under the control of our background garbage collection process but it lead me to wonder whether the userspace rm operation couldn't do something relatively simple to the file's inode data and then leave the actual resource group purging to happen in the background? This is obviously more complex to handle and in the case where an rm occurs and then there is immediately a demand for blocks where the only blocks possibly available were assigned to the rm'd file (i.e. the fs was full and the file was rm'd to make space) the block allocator would need to wait for the cleanup to occur. Would this be something worth considering as a future improvement or is it just too complicated to envisage? Mark.
