![]() | |||||||||||||
Messages in this thread |
* Jan Engelhardt <jengelh@medozas.de> wrote: > 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/ --------------------------------------------------------------------- | ||||||||||||
| Last update: 2008-05-11 18:41 [W:0.817 / U:0.020 seconds] ©2003-2008 Jasper Spaans | |||||||||||||