From: Enrico Weigelt <weigelt@metux.de>
To: linux kernel list <linux-kernel@vger.kernel.org>
Subject: Re: Deleting large files
Date: Sun, 11 May 2008 18:38:05 +0200 [thread overview]
Message-ID: <20080511163805.GA11175@nibiru.local> (raw)
In-Reply-To: <alpine.LNX.1.10.0805111229520.19952@fbirervta.pbzchgretzou.qr>
* 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/
---------------------------------------------------------------------
next prev parent reply other threads:[~2008-05-11 16:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-07 19:49 Deleting large files Morten Welinder
2008-05-07 20:10 ` Jan Engelhardt
2008-05-07 20:17 ` Xavier Bestel
2008-05-07 20:48 ` Jan Engelhardt
2008-05-07 22:34 ` linux-os (Dick Johnson)
2008-05-07 23:14 ` Morten Welinder
2008-05-08 23:01 ` Alan Cox
2008-05-11 10:30 ` Jan Engelhardt
2008-05-11 16:38 ` Enrico Weigelt [this message]
2008-05-20 14:33 ` Pavel Machek
2008-05-08 8:19 ` Matti Aarnio
2008-05-11 11:16 ` Christoph Hellwig
2008-05-11 16:42 ` Aneesh Kumar K.V
2008-05-08 17:29 ` Christian Kujau
[not found] ` <118833cc0805081110u7aad3921v3a1ec4187acc4ef4@mail.gmail.com>
2008-05-08 18:54 ` Christian Kujau
2008-05-17 12:15 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080511163805.GA11175@nibiru.local \
--to=weigelt@metux.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox