> 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.
-
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/