Messages in this thread |  | | From | (Remy Card) | Subject | Re: ext2fs "performace" | Date | Fri, 21 Jun 1996 13:36:35 +0200 (MET DST) |
| |
Harald Koenig wrote:
> running Linux-2.0.0 on a 83 MHz Pentium OverDrive with fast SCSI disk > using a 2.6 GB ext2fs partition with only two files with 1GB size each > I removed these files. removing only one file took 100 seconds real time !!
Ok, this a known problem: when a file is removed, its size is set to zero and the truncate operation is called to deallocate data blocks. The problem is that truncate zeroes every block address in the indirect, dindirect, and tindirect blocks and marks these blocks as dirty so that they will be written back on the disk.
I do have patches that change this: when removing a file, a special function ext2_remove is called. This function deallocates data blocks but does not modify block addresses. There are several advantages: - it is faster (see below), - it should be easier to recover a deleted file, since the block addresses have not been lost, - by using a special function when a file is removed, it should be possible to re-enable the "secure deletion" feature that was disabled during development of the 1.3 kernel, because it was conflicting with truncate.
Anyway, here are some benchmarks that I have run on a 600 MB file:
With Linux 2.0: --------------- bbj# time rm /3/BIG.1 ; time sync 0.00user 1.17system 0:39.25elapsed 2%CPU 0.00user 0.30system 0:03.90elapsed 7%CPU
With Linux 2.0 + my patch: -------------------------- bbj# time rm /3/BIG.1 ; time sync 0.00user 0.48system 0:23.22elapsed 2%CPU 0.01user 0.33system 0:00.52elapsed 65%CPU
With Linux 2.0, we have a "removage rate" of 15.29 MB per second, with my patch, the "removage rate" is 25.84 MB per second.
I plan to tune this patch and to submit it to Linus for inclusion in the 2.1 kernel.
Remy
|  |