| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Sun, 11 May 2008 18:38:05 +0200 From: Enrico Weigelt <weigelt@...ux.de> To: linux kernel list <linux-kernel@...r.kernel.org> Subject: Re: Deleting large files * Jan Engelhardt <jengelh@...ozas.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/ --------------------------------------------------------------------- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists