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:	Fri, 9 May 2008 00:01:24 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	"Morten Welinder" <mwelinder@...il.com>
Cc:	"linux-os (Dick Johnson)" <linux-os@...logic.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Deleting large files

> user experience.  Forking a process to do the deletion (a) is pathetic,
> (b) is not currently done, and (c) does not work: you cannot get a result
> right away, i.e., you lose error handling.

I wouldn't call it pathetic. Quite a few big media file tools create a
thread to do deletions of big objects.

The error handling isn't usually a problem. You know any error you can do
anything meaningful with actually occurs immediately or close to it. If
you get errors because of I/O problems in a minutes time there isn't a
sensible response and recovery anyway - nor would a kernel side
asynchronous delete be able to recover any better.

In theory you can push some kind of asynchronous delete threads into the
kernel or extent the AIO interfaces we have to do AIO_delete but at the
end of the day the implementation would effectively be create thread,
unlink, exit - and you can do that neatly and sanely in user space.
--
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/