* Jan Engelhardt <jengelh@medozas.de> wrote:

quoted text
> Iff a process still has the file open, your unlink will succeed immediately
> anyway, and the real deallocation takes place when the last process runs
> close(). Which shows an interesting fact too: not only unlink can block.

Yep, the point is: on *nix there is no delete syscall, but just 
an unlink (decreasing the refcount). The kernel then decides when
to actually remove the file (normally when refcount==0).

So, when refcount==0 the kernel (more precisely: the fs) could
just hand over the inode to some kthread, which does the actual 
space-reclaiming. When properly done, the case of powerfail will
catched by fsck or journal replay, just the same as when several
processes were in the middle of deleting files.

Maybe this could be implemented by an overlaying filesystem,
which essentially moves to some special deleted dir instad of 
real unlink'ing - an separate process (which even could run in 
userland) will do the actual unlinking. So when an user process
calls unlink(), the inodes don't even have to be touched.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/