linux-kernel - Re: Deleting large files

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 7 May 2008 22:10:26 +0200 (CEST)
From:	Jan Engelhardt <jengelh@...ozas.de>
To:	Morten Welinder <mwelinder@...il.com>
cc:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Deleting large files

On Wednesday 2008-05-07 21:49, Morten Welinder wrote:

>Hi there,
>
>deleting large files, say on the order of 4.6GB, takes approximately forever.
>Why is that?  Well, it is because a lot of things need to take place to free
>the formerly used space,

Only for a few filesystems which use that sort of housekeeping.

>but my real question is "why does the unlink caller have to wait for it?"

Same reason your shell waits for your program to complete before
showing the prompt again?

>I.e., could unlink do the directory changes and then hand off the rest of the
>task to a kernel thread?

Say you had one realtime application running that would do lots of new
writes after the unlink finished. When the unlink is put into the
background, you interleave the unlink operation with new writes,
probably causing needless seeks and therefore not hitting the deadlines
anymore.

For you desktop use, `rm -f foobar.avi &` should do. No?
--
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/