Linux-kernel mailing list archive 1999-20,: Re: Deletion of big files...

# Re: Deletion of big files...

Jan Kara (jack@atrey.karlin.mff.cuni.cz)
Tue, 18 May 1999 12:28:13 +0200

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Tim Waugh: "Re: My 3 big wishes for 2.3.x"
- Previous message: Horst von Brand: "Re: Capabilities done right [diff against 2.3.1]"

>
>
> 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.
>
<snip>
> 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.
IMO this handling of truncate will increase disk fragmentation as balloc() would
think the block is allocated even if it can be freed so to prevent this we would have to
go through the queues - nasty as we would have to handle indirect blocks somehow...
Also when we are going to free some block we have to capture ext2 superblock lock and
I'm looking forward to those beatiful deadlocks ;-). (OK I agree this can be avoided...).
And anyway everything we achieve is just delaying of the work so when we start flushing
free blocks the fs will be as unusable (superblock lock held) as during rm... So IMHO it's
no worth problems which might arise... I think more finegrained locking (not just one big
sb lock) would be bigger win but it's issue for ext3.

Honza.

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

- Next message: Tim Waugh: "Re: My 3 big wishes for 2.3.x"
- Previous message: Horst von Brand: "Re: Capabilities done right [diff against 2.3.1]"