> 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