Re: Deletion of big files...
Jorge Gonzalez Villalonga (jorgegv@icai.upco.es)
Mon, 17 May 1999 10:25:39 +0200
Alexander Viro wrote:
>
> On Sat, 15 May 1999, Pavel Machek wrote:
>
> > Well, if you went for completely async unlink...
> >
> > rm bigfile
> > <use of lots of disk space>
> >
> > could fail due to "out of disk space", where sync remove does not have
> > this problem.
> >
> > So it is not as easy as it seems.
>
> I'm not sure... Look: we spend time *not* in unlink() pre se. It's a final
> truncate(). And at the moment when it's called we *know* that we are sole
> owners of the thing and nothing else will ever try to touch it. So
> basically we have a bunch of blocks we should free + bunch of indirect
> blocks of varying orders. They are goners and we don't have to care about
> any races. Suppose we have a kernel thread that has several queues. Each
> queue has eater function and consists of resources to be freed. Each has
> associated watermarks. fs driver can register a queue and can submit
> requests. If the amount of outtstanding requests exceeds the upper
> watermark for queue thread wakes up and consumes some amount of requests.
> OK, now let's register several queues:
> 1. ranges of ext2 blocks for freeing. Action: mark them free in the
> bitmap.
> 2. ext2 indirect blocks for freeing. Action: read the block, go through
> its contents and feed the appropriate requests into the queue 1 (including
> the block itself).
> 3. Ditto for double indirect blocks. Queues being fed: 2 and 1.
> 4. Triple indirect. Ditto, target queues 3 and 1.
> 5. Ext2 inodes for freeing. Action: feed appropriate requests to #1--4 and
> mark inode free in inode bitmap.
> Now, if ext2 driver fails to find a free inode or block (or simply feels
> that it's low on those resources) it can wake up the reaper thread.
>
> Methink this scheme might work. The main problem here being that we should
> deal with quotas in process. So looks like requests should contain the
> information on owner.
>
> Reaper may need an interface for hinting which queues should be processed
> first, indeed.
>
> I can try to implement it, but I'ld like to hear comments on that thing.
This is exactly what I meant when I said that probably a whole thread
just for unlinking was overkill. This scheme that you propose seems
great.
Regarding quotas, I really don't mind if my users are over quota for
some seconds. And if they are below, well, they can surely wait ten
seconds to get the quota correct, can't they?
--
Jorge Gonzalez <jorgegv@icai.upco.es> -o)
ICAI - Universidad Pontificia Comillas /\\
Administrador de Sistemas _\_v
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/