Hacker News Reader

Comment by tumult | Hacker News Reader

No. There is not 60TB of data on the disk, which is what the GUI is reporting in the article. The GUI doesn't say that 60TB of data would exist if the snapshots were each individually flattened and expanded to another filesystem. It says there is 60TB of data filling the disk.

View on HN

However, the code traverses that amount of data. It doesn't matter if you pass over the same inode n times. From OS point of view, there's no difference.

Of course you can write a more complicated calculation algorithm, but it'll require tons of syscalls to determine the type of the file handle you're interacting with and will be probably very slow.

This is what rustup did inadvertently back in the day, and it caused NTFS to melt down to a halt because of stat() overhead [0].

[0]: https://www.youtube.com/watch?v=qbKGw8MQ0i8

Why does the user care about how many times an iterator passes over an inode? The Finder is reporting incorrect information to them and may lead them to make bad decisions, like buying unnecessary external storage drives. You've missed the point of the article.

I don't think so, because a) macOS provides correct free space information, b) It explicitly says that "your backup disk is full, and I'll open up some space, so your earliest backup will be at $DATE", before actually deleting any snapshots.

Our disagreements stem from the assumption that the reported space is incorrect to begin with, but there's already "disk on space" note on every file, which provides physical size of something.

We can argue that the progress may be calculated over that number, but I still think it has its own limitations with performance.

I think that's fair when you consider it all together.

What happens then if you try to copy that 2TB of 'data' to a filesystem that doesn't support links? 60TB would be used in that case.

There are some use cases that are computationally expensive to figure out and don't have a simple/easy answer to solve.

That's not the information that dialog is purporting to display. That's a theoretical thing you've made up for this comment.

It's a real thing that happens all the time when copying. Delete is a different operation, but now you're asking for a different space calculator when performing delete which will have its own set of bugs and performance issues.

Hard links are a pathological case.

Reply on news.ycombinator.com