Why is networking and deleting trash sooooooo slooooooow?

I mean, when downloading the buildtools and haiku source code, I only get about 350Kbytes/sec.

When deleting the entire /haiku (source code) folder, it takes forever! Yet it’s only a little over 1Gbyte in size. I can delete a single 600Mb Haiku Nightly .iso file and it takes a second or two. Is it the number of files in the folder that is causing the problem or…?

Dunno I think there is some buffering issue in the native ethernet / wifi drivers… for instance when in a VM it goes much faster.

Also deleting lots of files is much different than deleting one large file… the former is much much more complex. That is not to say that it shouldn’t be faster… are you using a hard drive or SSD just curious?

It’s an internal SATA hard drive in my Lenovo N580 laptop.


Deleting does not erase the file contents from disk, it just goes through each file and removes it from its parent folder. When you remove a whole directory, normally you could just remove that from its parent and be done, but we have something that gets in the way.

In Haiku, we have “node monitoring” which means any application can watch a file or directory and be notified when it changes. So, it means deleting a directory must now check all files and directories inside and make sure no one is watching any of them, or send notifications if someone is indeed watching.


I think that node monitoring is not main issue, otherwise 100% CPU core load will be expected during deletion, that is not observed. Possible problems are inefficient write cache/journal handling and bad handling of many small files in BFS by design. #15585 also cause to feel file deletion slower, because progress periodically pause, but it seems not affect deletion time in total.

Node monitoring is not unique BeOS/Haiku feature, other major OS have it.

I would expect browsing all subdirectories and files to be IO-bound, not CPU-bound.

The “monitoring” idea is of course not unique, the main difference is that on BeOS/Haiku it is based on a “node” (filesystem inode). This means you can monitor something without knowing its path. This makes it difficult to handle deletion of a parent directory, because you can’t do a simple path comparison to know if some monitored thing is part of the tree you just deleted. You have to browse the whole tree and check each node one by one.

And yes, it is probably not the single thing that takes time in the deletion process.