[clue-tech] Why is rm so slow?

[dennisjperkins at comcast.net]

 -------------- Original message ----------------------
From: Angelo Bertolli <angelo at freeshell.org>
> David L. Willson wrote:
> > I think this is the relevant bit.  Why do deletions on FAT and NTFS go off 
> instantly and
> > EXT* removals take time in direct proportion to file-size?  Is there a 
> fundamental
> > difference in how the filesystems work?  If so, what benefit are we getting 
> for the
> > overhead?
> >
> >   
> Yes, definitely they function differently.  I'm not that familiar with 
> how NTFS works, but not all filesystems are equal:  some can be mostly 
> (or strictly I guess) better than others.  In the case of FAT you don't 
> even have a journal:  that alone should make it faster in most cases I 
> would think.  (But if you pull the plug on your system, you risk being 
> in an inconsistent state.)
> 

When you delete a file, two things happen:  It gets removed from the directory, and every data block or cluster is returned to the pool of free disk blocks.    The bigger the file, the more time it takes.  The bigger the block, the less time it takes.  

FAT has larger block sizes as the drive capacity gets larger.  I don't know about NTFS, but I suspect it does the same.  

If I recall correctly, mke2fs lets you specify the block size for ext2/ext3.  If you are going to deal with a lot of small files, choose a small block size and lots of inodes.  If you are going to deal with large files, choose a larger size. 

I don't recall where the block table is located in ext2.  Maybe in the superblocks, but that might be too simplistic.  When a file needs a new block, the filesystem might preallocate a few adjacent blocks on the assumption that the file might grow larger and to minimize fragmentation.  I would need to reference a book on Linux filesystems to see how it is actually laid out.