Replies: 2 comments
-
Firstly, thank you for creating I am well aware of There are 2 main reasons why I decided not caring about hardlinks:
Not caring about hardlinks was a design choice, not a trade-off choice between speed and utility. But if, hypothetically, I want to detect hardlinks, I wouldn't aggregate all inodes into one When you finish your rewrite, can you notify me? I want to update the benchmarks. |
Beta Was this translation helpful? Give feedback.
-
@bootandy 🎉 Congratulation on the new release! It seems that the new implementation improved a lot as it rises from second-last place to second place in my benchmark. |
Beta Was this translation helpful? Give feedback.
-
Firstly good job, pdu is really fast.
If you create a hard symlink like this:
ln file hard_link
it appears twice in pdu where as it is only taking up one 'space' on disk. Both file and hard_link have the same Inode - Hence I only 'count' the disk space for one of them. Therefore in dust I chose to ignore the duplicate file as removing either 'file' or 'hard_link' wouldn't recover disk space until they were both removed.I'm curious to see how you would solve the above problem. I have tried and using channels (slow) and tried locks round a shared hashmap (even slower)
I'm in the middle of a dust re-write to see if I can make it faster based on some of your ideas. :-).
You can see me doing the check for duplicate inodes here:
https://github.com/bootandy/dust/blob/master/src/utils/mod.rs#L253
Beta Was this translation helpful? Give feedback.
All reactions