[lkml]   [1999]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Deletion of big files...
> 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.
> 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.092 / U:1.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site