Messages in this thread | | | Date | Tue, 18 May 1999 12:28:13 +0200 | From | Jan Kara <> | Subject | Re: 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. > <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/
| |