[clue-tech] Why is rm so slow?

[David L. Anselmi]

David L. Willson wrote:
> Actually, there is a file-attribute that flags for full file erasure on removal of the
> last link.  I can't call it to mind right now, but it's in the man pages for chattr and
> lsattr, I think.

Yes but that's the kernel, not rm.  I wonder whether rm blocks during 
the erase.  And it doesn't work on ext2/3.

> EXT3, dunno, default, FireWire800 to SATA, Are marginal blocks the ones on the edge of
> the platter, that you're not supposed to write to?  :-)

No, the margins are between the tracks.  That's where the marginal 
blocks hang out. :-)

> 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?

With ext3 freeing the blocks is probably fs metadata that's journaled. 
The journal is synchronous as well, right?  So that part of the process 
is synchronous where FAT isn't (and NTFS may not be either).

> Maybe I should do some more "timings".  It's been a long time since I used FAT or NTFS.
>  Maybe I'm just mis-remembering, but I don't think so...

Yeah, and if you want to trade journaling or other things you can 
certainly optimize ext (or another fs) so that large deletes are faster. 
  But there may be other things you care about when you sit down to 
think about it.

Dave